[squeak-dev] Re: DebuggerUnwindBug>>testUnwindDebuggerWithStep

Norbert Hartl norbert at hartl.name
Tue Jul 1 07:16:57 UTC 2008


On Mon, 2008-06-30 at 16:10 -0700, Andreas Raab wrote:
> Norbert Hartl wrote:
> > What does this
> > 
> > <primitive: 19> "Simulation guard" 
> > 
> > do?
> 
> It does nothing. It only indicates that the system will crash if that 
> code ever gets simulated (usually due to atomicity violations).
> 
> > Hmmm, looks quite confusing to me as the suspendingList is
> > only one element in size the whole time. Hmmm...
> 
> Yeah, indeed. That is interesting. I don't have the time to look at this 
> right now but it may actually be the solution to the problem. I think 
> that a strategically placed #suspend in completeStep: may solve this 
> problem. I'll have to think about this more ...
> 
I had another look and I don't understand why the suspendingList has
to be nil after the completeStep:. It is just a step over the wait.
No signal happens nor any other cleanup. Or do you think completeStep:
should somehow detect that it steps over a wait?
> > Anyway my conclusion is that the test in my first post can't work.
> 
> Not sure how you come to this conclusion. The test *doesn't* work but 
> that indicates that a piece of the system is broken.
> 
The test sets up a context with "sema wait". One step further it enters
the critical: context (stepping over sema wait). The next instruction
"top delete" sends terminate to the process. And Process>>terminate
does a "suspendedContext home" which prevents the sema from being 
signalled (as the comment says). So the assumption of the test that
the sema has to be signalled at that time is wrong.

Norbert
> > Any suggestions which side needs a change?
> 
> Simulating "out of" a semaphore wait is broken. The debugger test is 
> still valid btw, since it illustrates the behavior in a practical manner.
> 
> Cheers,
>    - Andreas
> 




More information about the Squeak-dev mailing list