Hi, On Mon, Nov 04, 2002 at 03:50:47PM +0100, Russell Coker wrote: > I have attached a couple of test programs demonstrating a problem that I have > with expect. > > I type the following: > ./expect_script ./testit > > The result I desire is that the command "sleep 100" is running in the > background. However sleep doesn't seem to get run. > > I can't determine the exact cause of the problem because all methods of > tracing it (strace etc) stop it occurring). > > Putting a "sleep 1" at the end of the testit script will solve the problem, > however in the REAL situation that this test is similating I don't get to > change the script that is run from expect... I've had a race like that in a program of mine. Strace stopped it from happening, so did gdb, and then what? In my case it happened when a (possibly tty-related) signal got delivered to the new process that is created by fork. In the small period of time between a fork() and a subsequent execve(), a signal intended for the child process gets handled by the signal handler in the parent, causing it to terminate. So, fork() inherits signal handlers. That was a hard lesson. I solved this by making the signal handlers check getpid() against the pid that was saved in a global variable when the handlers were installed, before having them do anything. Perhaps the fast terminating of the parent process in setsid may cause a tty-related signal to be delivered to the just forked child, which terminates it before it gets a chance to call setsid() to detach it from the tty. As you can see, you can have nasty races without multithreading ;-) Cheers, Emile. -- E-Advies / Emile van Bergen | emile@e-advies.info tel. +31 (0)70 3906153 | http://www.e-advies.info
Attachment:
pgp7Icm25SpWI.pgp
Description: PGP signature