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
> 


>