OSProcessPlugin loads incorrectly in a squeak-dev 49 image

> On Nov 18, 2006, at 21:18 , David T. Lewis wrote:
>
> >Right, in Squeak a Process is like a "green thread". However, the  
> >underlying
> >VM may choose to use threads for its own purposes, and specific  
> >plugins may
> >do so also even if the VM is single threaded.
>
> Dave,
>
> I'm currently puzzled by a thread / signal related problem on OLPC.  
> Ian recently added an ALSA sound module which we use. Also, I'm using  
> AsyncFile for reading commands from a pipe. Commands that I send  
> include disabling/enabling of sound. Now, the problem is, as soon as  
> I re-enable the sound via an async command, the VM is terminated by a  
> SIGIO. I suspect it related to ALSA which forks off a thread, because  
> in the main VM we actually have a handler for SIGIO. Ian thinks it  
> might have to do with the AsyncFile plugin. Unfortunately, I have no  
> idea how to debug this ... do you?

> Excuse me for following up on my own reply, but it occurs to me that
> a much easier way to figure out what is happening to the SIGIO handler
> is to just set a gdb breakpoint on the signal() call. Do this right
> before you re-enable the sound via the async command, and you will
> probably break on some plugin trying to restore the signal handler
> to its default value (which would be incorrect).
>
> Dave
>
>
> On Sun, Nov 19, 2006 at 10:10:24AM -0500, David T. Lewis wrote:
>> On Sat, Nov 18, 2006 at 10:49:05PM +0100, Bert Freudenberg wrote:
>>> On Nov 18, 2006, at 21:18 , David T. Lewis wrote:
>>>
>>>> Right, in Squeak a Process is like a "green thread". However, the
>>>> underlying
>>>> VM may choose to use threads for its own purposes, and specific
>>>> plugins may
>>>> do so also even if the VM is single threaded.
>>>
>>> Dave,
>>>
>>> I'm currently puzzled by a thread / signal related problem on OLPC.
>>> Ian recently added an ALSA sound module which we use. Also, I'm  
>>> using
>>> AsyncFile for reading commands from a pipe. Commands that I send
>>> include disabling/enabling of sound. Now, the problem is, as soon as
>>> I re-enable the sound via an async command, the VM is terminated  
>>> by a
>>> SIGIO. I suspect it related to ALSA which forks off a thread,  
>>> because
>>> in the main VM we actually have a handler for SIGIO. Ian thinks it
>>> might have to do with the AsyncFile plugin. Unfortunately, I have no
>>> idea how to debug this ... do you?
>>
>> Hi Bert,
>>
>> I don't see how it could be the AsyncFilePlugin, because that  
>> plugin does
>> not manipulate any signal handlers. And assuming that the VM is  
>> exiting
>> cleanly (as opposed to a seg fault), then the problem is not  
>> likely to be
>> caused by pthread signal delivery, although this could also be a  
>> separate
>> problem.
>>
>> A plausible scenario might be:
>>
>> - VM sets its signal handler for SIGIO.
>> - Some plugin sets the SIGIO handler for its own purposes, but  
>> does not
>>   bother to remember the prior signal handler setting.
>> - The plugin decides that it is done, and restores the SIGIO  
>> handler to
>>   its default value instead of restoring the handler to the one  
>> that the
>>   VM wants to use.
>> - The next SIGIO that arrives goes to the default handler, which  
>> terminates
>>   the VM.
>>
>> I am attaching a change set that may help narrow the problem down.  
>> You
>> can use it to list the values of signal handlers, and you can also  
>> set your
>> own signal handler that forwards SIGIO to a semaphore in the image,
>> overriding any handler that was previously set by either the VM or a
>> plugin. For example, in a workspace:
>>
>> --- workspace example --
>> "List all current signal hander addresses to Transcript or to Unix  
>> console"
>> OSProcess accessor listSigHandlerAddressesOnConsole.
>> OSProcess accessor listSigHandlerAddressesOnTranscript.
>>
>> sigIoNum := 29. "check to see that this matches your Linux system"
>> OSProcess debugMessage: 'SIGIO is ', sigIoNum printString.
>>
>> "Figure out the current C pointer address of the SIGIO handler"
>> previousHandlerAddress := OSProcess accessor  
>> currentSigHandlerAddress: sigIoNum.
>> OSProcess debugMessage: 'SIGIO hander is ', previousHandlerAddress  
>> printString.
>>
>> "Forward SIGIO to the image to prevent the VM from exiting"
>> sema := OSProcess accessor forwardSignal: sigIoNum.
>> sema inspect. "watch excessSignals in the semaphore"
>>
>> "Now you can do 'kill -29 <squeakpid>' from Unix command line, and
>> the excessSignals will increment in the semaphore."
>>
>> "Revert to prior signal handler, and undo signal forwarding"
>> unregisteredSema := OSProcess accessor restoreSignal: sigIoNum.
>> --- end workspace example ---
>>
>> You'll need OSProcess and an OSProcessPlugin, which I assume you can
>> add for purposes of debugging. If you build an OSPP from source, I  
>> would
>> suggest using the latest from SqueakSource (not released), which is
>> http://www.squeaksource.com/OSProcessPlugin/VMConstruction-Plugins- 
>> OSProcessPlugin-dtl.5.mcz
>>
>> Before building, edit platforms/unix/plugins/UnixOSProcessPlugin/
>> acinclude.m4
>> to contain these two lines:
>> AC_CHECK_FUNC(unsetenv, AC_DEFINE(HAVE_UNSETENV, 1))
>> AC_PLUGIN_CHECK_LIB(pthread, pthread_kill)
>>
>> Then do 'cd platforms/unix/config; make' to update the configure  
>> script before
>> doing the build. While you're at it, if you can ask Ian to check  
>> the acinclude.m4
>> change into Subversion, that would be helpful.
>>
>> I'd be happy to try some debugging on my end if you think it might  
>> help,
>> although my Linux system is rather old:
>> Linux version 2.4.21-303-default ([hidden email]) (gcc version  
>> 3.3.1 (SuSE Linux)) #1 Tue Dec 6 12:33:58 UTC 2005
>>
>> Dave
>>
>
>
>>
>