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: SignalDebugging-dtl.1.cs.gz
Type: application/octet-stream
Size: 2065 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061119/13e35b36/SignalDebugging-dtl.1.cs.obj