BTW, you wouldn't kill a process *while* it is trying to execute SortedCollection>>add: would you? Because this might get you a nil in SuspendedDelays faster than you could say "oops". And I agree with your analysis that something must be signaling the mutex twice but I will point out that one of the processes was the wx event loop which may very well be invoked via unlikely places (if I remember the discussion with Rob then he had serious problems getting wx to work asynchronously).
Cheers, - Andreas
Cees De Groot wrote:
Thanks John & Tim, for these suggestions. I'll continue debugging tonight (have to work in VisualAge today, work hard, earn money) and post as I make progress (or not).
Regards,
Cees
On 2/2/06, John M McIntosh johnmci@smalltalkconsulting.com wrote:
Well if you recall a couple of weeks back I had a changeset that turns on printing of the stack in message send, so you can see the stack on each message send by process.
Mind you'll need to build a VM for this, plus write some code to read the log file and determine how the semaphore signalling is done.
Or of course change the VM to note the excessive semaphore signalling and print the stack when it happens, and as Tim points out use the Special objects array to track the semaphore of interest.
On 1-Feb-06, at 3:42 PM, Cees De Groot wrote:
On 2/1/06, Cees De Groot cdegroot@gmail.com wrote:
On IRC, Jecel Assumpção remarks that the Semaphore in both cases is 'in rest' - excessSignals is 1, where 0 would be expected when the critical section is active. And -1 when two critical sections are active :-)
Any suggestions on how we could proceed?
Thanks,
Cees
--
=== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===