[squeak-dev] DebuggerUnwindBug>>testUnwindDebuggerWithStep

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

> So having looked more closely into this issue I am by now convinced  
> that this is a bug in the simulation machinery. The point is that  
> we're simulating stepping out of a semaphore wait, e.g.,
>
>  sema := Semaphore new.
>  process := [sema wait] forkAt: Processor activePriority + 1.
>  ctx := process completeStep: process suspendedContext.
>
> At this point we're out of the semaphore wait and consequently the  
> suspendingList of the process should be nil but it ain't. I've  
> attached two tests which illustrate the problem.
>
> Cheers,
>  - Andreas
>
>
> Andreas Raab wrote:
>> 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
>>>
>>>
>>>
>
> <SimulationBugs.st>

> So having looked more closely into this issue I am by now convinced that
> this is a bug in the simulation machinery. The point is that we're
> simulating stepping out of a semaphore wait, e.g.,
>
>    sema := Semaphore new.
>    process := [sema wait] forkAt: Processor activePriority + 1.
>    ctx := process completeStep: process suspendedContext.
>
> At this point we're out of the semaphore wait and consequently the
> suspendingList of the process should be nil but it ain't. I've attached
> two tests which illustrate the problem.
>

> Cheers,
>    - Andreas
>
>
> Andreas Raab wrote:
> > 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
> >>
> >>
> >>
> >
> >
> >
>

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