David thank you for doing this work, I've put your changesets and my  
altered changsets  on my ftp server.
(got to love = versus == issues as always in C, 27 years of practice  
and I still can get it  right).
I will remark seeing a Microsoft Ad lately talking about C buffer  
overflow issues and how MS was *solving* the issue by training their  
staff, "can you spot the error", and
thinking, duh a Smalltalker would call the existing method to do that  
str concatenation, versus writing a hunk of C code.


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....

Perhaps in

primitiveSetVMStatsTraceMessageSendLevels

only set vmStatsTraceMessageSendLevels to say (-1) if goes to zero   
and leave vmStatsTraceMessageSendStorageFile alone, don't close the  
file.

then in printCallStack1OnlyOf if
vmStatsTraceMessageSendLevels is < 0 and if  
vmStatsTraceMessageSendStorageFile  is not zero close file and always  
set vmStatsTraceMessageSendStorageFile &  
vmStatsTraceMessageSendLevels to zero, and return.

later if we get another set to zero signal, we'll invoke  
printCallStack1OnlyOf but do nothing
or if we get set to N we'll see vmStatsTraceMessageSendStorageFile =  
0 and reopen the file.



On 2-Nov-05, at 2:46 PM, David T. Lewis wrote:

> I have to mention that I have seen a nasty problem that I don't
> understand. On two different occasions while I was writing and
> debugging this, I ended up the stats trace log data being written
> to my changes file (with horrible results, needless to say). I do
> not know what the cause was, I don't know how to reproduce it, and
> I don't know if it's related to the signal handling or something
> else in the interpreter changes. In any case, be on the lookout
> for this bug, and save your image rather more often than you
> might otherwise do.

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===