[Etoys-notify] [JIRA] Resolved: (SQ-262) recreateSpecialObjectArray hangs waitForCommand:

[jira at immuexa.com]

     [ http://tracker.immuexa.com/browse/SQ-262?page=all ]
     
K. K. Subramaniam resolved SQ-262:
----------------------------------

    Resolution: Complete

The root cause is the reconstitution of specialObjectsArray effectively lost a semaphore created on startup by a class. OSProcess used one to track child process exits. This could happen to any class that creates semaphores on startup.

Thanks to Dave, I could temporarily patch a reinitialization for OSProcess accessor in this case.
  OSProcess accessor
     primForwardSignal: OSProcess accessor primSigChldNumber
     toSemaphore: nil.
  Smalltalk recreateSpecialObjectsArray.
  OSProcess accessor initialize.

ReleaseBuilder* is a one-off case, so I will close this bug for now.

> recreateSpecialObjectArray hangs waitForCommand:
> ------------------------------------------------
>
>          Key: SQ-262
>          URL: http://tracker.immuexa.com/browse/SQ-262
>      Project: squeakland
>         Type: Bug
>   Components: etoys-linux
>     Reporter: K. K. Subramaniam

>
>
> The message send:
>    Cursor wait showWhile: [ OSProcess waitForCommand: 'sleep 3' ]
> hangs indefinitely, if done after:
>    ReleaseBuilderSqueakland new prepareReleaseImageForSqueakland.
> I was able to refine it down to the recreateSpecialObjectsArray send in finalStripping. OSProcess works fine just before this send and breaks just after this send.
> The behavior was seen on Squeak3.10.3beta of 22 July 2007 [latest update: #7159] on etoys4#2229 (dev image) with OSProcessV4-3-7 loaded. The bug also surfaces with OSProcessV4-3-6.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://tracker.immuexa.com/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira