[squeak-dev] Re: DebuggerUnwindBug>>testUnwindDebuggerWithStep
Andreas Raab
andreas.raab at gmx.de
Sat Jun 21 22:27:09 UTC 2008
Hi Norbert -
Good find. The test is interesting since it illustrates behavior that
can *only* happen during simulation. Unless simulated, the return from
the preceding wait and the activation of the block are atomic so you'd
never be able to get into the spot that this particular test uses. The
test itself was intended to show a somewhat different problem but it
should be made to work since I don't see why one should't be able to
terminate the debugger in this spot and expect things to work. I'll have
to ponder this one a little since there are many implications there.
Cheers,
- Andreas
Norbert Hartl wrote:
> This test case appears at some point to fail. It succeeds in 3.9.
> I narrowed the problem to an update of 3.9.1 with update 7071
> (Kernel-sd.151) which introduced it.
>
> The piece of code that triggers it is:
>
> Process>>terminate
> ...
> suspendedContext ifNotNil: [
> "Figure out if we are terminating the process while waiting in
> Semaphore>>critical: In this case, pop the suspendedContext so that
> we leave the ensure: block inside Semaphore>>critical: without
> signaling the semaphore."
> (inSema == true and:[
> suspendedContext method == (
> Semaphore compiledMethodAt: #critical:) ]) ifTrue:[
> suspendedContext := suspendedContext home.
> ].
> ...
>
> I don't really understand the rationale behind doing this but it
> seems that it conflicts with the test assumption:
>
> DebuggerUnwindBug>>testUnwindDebuggerWithStep
> ...
> debugger doStep.
> "close debugger"
> top delete.
>
> "and see if unwind protection worked"
> self assert: sema isSignaled.
>
> As I don't really understand what happens and what should happen I would
> be glad to hear some words of advice.
>
> Norbert
>
>
>
More information about the Squeak-dev
mailing list
|