[M3devel] FW: thread.fork getting nil on nt386gnu?

[Jay]

My mail keeps getting truncated.
I'll at least pay for hotmail to remove the annoying ads, maybe that'll help..
 



From: jayk123 at hotmail.com


Same thing..I should look into what the underlying representation is and why it changed from "working" to non working.Note that this code runs about three times in the relevant scenario and only "fails" the third time, but yet, I'm pretty sure but will double check, the error message is plain wrong. I think I saw it run the thread function, it wasn't actually NULL. I'll have to double check that though. Imho, it could /easily/ be inspecting other nearby data that just happens to usually not be zero on NT386 but happens to sometimes be zero on NT386GNU. Without commiting the change, running the same code on pthreads/alarmthreads on other platforms might be "interesting". I wouldn't bet either way. I find there are bugs /everywhere/. Code that is trying to find bugs is no more immune from bugs than the code it is attempting to check. More code leads to more bugs. More asserts lead to more incorrect asserts. More runtime checks lead to more incorrect runtime checks. etc. Of course, checks are still good, and like everything else they must be written carefully and like everything else, when things go apparently wrong, pretty much all code should be assumed wrong until proven otherwise (read it, run it, read what it depends on, etc.). Code is guilty until proven innocent, many times. One rotten apple spoils the bunch....  - Jay



CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] thread.fork getting nil on nt386gnu?Date: Fri, 7 Mar 2008 18:17:55 -0500
This wasn't an ASSERT assertion.  It was an explicit check that the apply method was not null, along with a helpful message to the user.


On Mar 7, 2008, at 4:38 PM, Jay wrote:

Assertions, like a lot of code, often succeed by luck.There's little point in asserting a pointer isn't null right before dereferencing it. You are going to crash on one line or the next.  - Jay


CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] thread.fork getting nil on nt386gnu?Date: Fri, 7 Mar 2008 14:48:29 -0500Umm.  If the assertion is wrong then how has this code ever run before... 



On Mar 7, 2008, at 2:21 PM, Jay wrote:


assertions are also notoriously wrong.Two out of three thread implementations don't have it..  - Jay


CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] thread.fork getting nil on nt386gnu?Date: Fri, 7 Mar 2008 08:41:23 -0500
It is always dangerous to remove assertions that have worked in the past.  Better to understand why they no longer work.  Anyway, what this suggests is something in alignment because what the assertion checks is that the method table for the Thread.Closure object passed to Thread.Fork contains a non-NIL function pointer in the "apply" slot.


Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484


On Mar 7, 2008, at 1:00 AM, Jay wrote:

This asssertion is absent from the two other thread implementations, and is dependent on a loophole to underlying details that I didn't track down to determine if they are corrrect. So I merely removed this. Still can't connect to the X server for some reason..  - Jay


CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] thread.fork getting nil on nt386gnu?Date: Tue, 26 Feb 2008 13:29:28 -0500Looks like a corrupted/uninitialized type (method table contains a NIL pointer...). 



Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484


On Feb 25, 2008, at 1:15 PM, Jay wrote:

any obvious ideas? I'll have to pause for a bit again..Jay at jay-win1 /cygdrive/c/dev2/cm3.2/m3-ui/juno-2/juno-app/NT386GNU/Juno.exe****** runtime error:***    Thread client error: NIL apply method passed to Thread.Fork!***    file "ThreadWin32.m3", line 578***  14837 [sig] Juno 3908 c:\dev2\cm3.2\m3-ui\juno-2\juno-app\NT386GNU\Juno.exe: *** fatal error - called with threadlist_ix -1Hangup  - Jay
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging. You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080308/5eb28eda/attachment-0002.html>