Dave,

Thanks for the pointers - you pushed me into the right direction.  
Turns out ALSA does not restore the VM's SIGIO handler but sets it to  
SIG_DFL :(

I implemented a workaround which seems to work (attached).

- Bert -

On Nov 19, 2006, at 19:38 , David T. Lewis wrote:

> 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 (root at i386.suse.de) (gcc version  
>> 3.3.1 (SuSE Linux)) #1 Tue Dec 6 12:33:58 UTC 2005
>>
>> Dave
>>
>
>
>>
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: ALSA.diff.gz
Type: application/x-gzip
Size: 800 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061123/4072e1ff/ALSA.diff.bin
-------------- next part --------------