On Wed, Nov 02, 2005 at 10:03:25PM -0500, David T. Lewis wrote:
<intermittent irreproducible bug description snipped>
On Wed, Nov 02, 2005 at 05:38:55PM -0800, John M McIntosh wrote:
I think the issue here (and might suggest you could make the change) is to set a flag on the signal change to avoid a race condition between the interpreter and the signal handler for access to the file handle. I wonder if the file gets closed by the signal as we are doing fprintfs....
It sure seems like it must be that sort of problem. Only thing is, nothing is being done in the context of the Unix signal handler. By forwarding the Unix signal to a Squeak Semaphore, we are ensuring that the signal handling work is done in the interpreter itself, hence no such race condition should be possible.
Unfortunately, noone has informed the bug of the impossibility of its existence, so it still seems to be happening.
I'll try harder to reproduce this, and see if your suggestion helps.
John,
I've not been able to reproduce this bug. I set up a shell script to signal Squeak with SIGUSR1 then SIGUSR2 continuously with 100msec delays, then did things in Squeak including filein/out, edit code, etc. The trace logging worked, and I had no further problems.
So... don't worry about the bug, it was probably just something dumb I did in the course of testing an earlier version of my changes.
Dave