Debugging freeze due to RecursionLock critical:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Debugging freeze due to RecursionLock critical:

Thomas Brodt
Hi all

while at debugging, I sometimes get a debugger freeze (actually 7.6RC,
but had the issue also on 7.3.1). The debugger window itself stands
still, all fields and lists disabled, while the rest of VW still works.
This is in our development image with tons of packages loaded, of
course. A vanilla image had no problem in a short test (of course).

Now I found that the debugger client waits on a semaphore that never
gets signalled. This is during a recursion lock critical: section. a
sample stack is attached below, might not be the right one for the
debugger problem, but shows the issue.

The point of interest is the #critical: method in RecursionLock:

    | activeProcess |
    activeProcess := Processor activeProcess.
    ^activeProcess == owner
        ifTrue: [aBlock value]
        ifFalse:
            [semaphore
                critical:
                    [owner := activeProcess.
                    aBlock ensure: [owner := nil]]]  

In my case, where I could attach to such a hanging process, owner of the
recursion lock was nil. But the test (owner == activeProcess) returns
false in that case, halting the current process. But shouldn't the
access be granted if owner is nil? The method #isLocked in RecursionLock
also tests for nil as owner and answers false if owner is nil. So should
the test rather be :

(self isLocked not or: [owner == activeProcess])

or maybe shorter

(owner == nil or: [owner == activeProcess])

I haven't yet found any reason why the vanilla behaves different, but
this might come out as a tedious task.

Has anyone any comments on this? Is this behavior right and the problem
might be somewhere else?

Thanks in advance

Thomas

======================================================================================

Name: BlockClosure>>ensure:  Priority: 50
Semaphore>>waitIfCurtailedSignal
Semaphore>>critical:
RecursionLock>>critical:
ProcessEnvironment>>at:ifAbsent:
Process>>exceptionHandlers
Process>>popExceptionHandler
optimized [] in BlockClosure>>on:do:
BlockClosure>>valueAsUnwindBlockFrom:
BlockClosure>>ensure:
BlockClosure>>on:do:
MethodContext(Context)>>doPrimitive:receiver:numArgs:boundByMethod:
MethodContext(Context)>>tryPrimitive:receiver:numArgs:boundByMethod:
MethodContext(Context)>>runMethod:numArgs:contextClass:
[] in MethodContext(Context)>>send:receiver:class:super:numArgs:
MethodContext(Context)>>findMethod:class:ifFound:
MethodContext(Context)>>send:receiver:class:super:numArgs:
MethodContext(Context)>>send:numArgs:
MethodContext(Context)>>sendNonImmediate:numArgs:
optimized [] in InstructionStream
class>>initializeXMisc:numberOfExtensions:combinationRule:
MethodContext(InstructionStream)>>interpretNextInstructionFor:
optimized [] in Context>>safelyInterpretNextInstructionFor:
BlockClosure>>ensure:
BlockClosure>>on:do:
MethodContext(Context)>>safelyInterpretNextInstructionFor:
optimized [] in Context>>step
BlockClosure>>ensure:
BlockClosure>>on:do:
MethodContext(Context)>>step
optimized [] in Context>>sendIntoBlockStartingWithCallee:
BlockClosure>>ensure:
MethodContext(Context)>>sendIntoBlockStartingWithCallee:
BlockContext>>stepToCtxtWithSameParentAs:
optimized [] in DebuggerService>>privateStepIntoBlock
BlockClosure>>ensure:
BlockClosure>>on:do:
DebuggerService>>privateStepIntoBlock
optimized [] in DebuggerService>>basicStepIntoBlock
optimized [] in [] in [] in DebuggerService>>performDebugOperation:
BlockClosure>>ensure:
BlockClosure>>on:do:
optimized [] in [] in DebuggerService>>performDebugOperation:
BlockClosure>>ensure:
BlockClosure>>on:do:
optimized [] in DebuggerService>>performDebugOperation:
optimized [] in [] in ProcessHandle>>performDebugOperation:
BlockClosure>>ensure:
BlockClosure>>on:do:
optimized [] in ProcessHandle>>performDebugOperation:



 "self isLocked not"

--
Mit freundlichen GrĂ¼ssen

Thomas Brodt
PORaBo Consulting
Tel. +41 71 666 76 52
Fax. +41 71 666 76 57
http://www.porabo.ch

Reply | Threaded
Open this post in threaded view
|

Re: Debugging freeze due to RecursionLock critical:

Dennis smith-4
This sounds related to the Symbol bug.  If you try and interpret code
(which the debugger does at the end of a block)
and if that code does
    string asSymbol
it freezes on the Lock in symbol since its trying to interpret the
Symbol code while already in it.
Cincom is aware of that one.


Thomas Brodt wrote:

> Hi all
>
> while at debugging, I sometimes get a debugger freeze (actually 7.6RC,
> but had the issue also on 7.3.1). The debugger window itself stands
> still, all fields and lists disabled, while the rest of VW still
> works. This is in our development image with tons of packages loaded,
> of course. A vanilla image had no problem in a short test (of course).
>
> Now I found that the debugger client waits on a semaphore that never
> gets signalled. This is during a recursion lock critical: section. a
> sample stack is attached below, might not be the right one for the
> debugger problem, but shows the issue.
>
> The point of interest is the #critical: method in RecursionLock:
>
>    | activeProcess |
>    activeProcess := Processor activeProcess.
>    ^activeProcess == owner
>        ifTrue: [aBlock value]
>        ifFalse:
>            [semaphore
>                critical:
>                    [owner := activeProcess.
>                    aBlock ensure: [owner := nil]]]
> In my case, where I could attach to such a hanging process, owner of
> the recursion lock was nil. But the test (owner == activeProcess)
> returns false in that case, halting the current process. But shouldn't
> the access be granted if owner is nil? The method #isLocked in
> RecursionLock also tests for nil as owner and answers false if owner
> is nil. So should the test rather be :
>
> (self isLocked not or: [owner == activeProcess])
>
> or maybe shorter
>
> (owner == nil or: [owner == activeProcess])
>
> I haven't yet found any reason why the vanilla behaves different, but
> this might come out as a tedious task.
>
> Has anyone any comments on this? Is this behavior right and the
> problem might be somewhere else?
>
> Thanks in advance
>
> Thomas
>
> ======================================================================================
>
>
> Name: BlockClosure>>ensure:  Priority: 50
> Semaphore>>waitIfCurtailedSignal
> Semaphore>>critical:
> RecursionLock>>critical:
> ProcessEnvironment>>at:ifAbsent:
> Process>>exceptionHandlers
> Process>>popExceptionHandler
> optimized [] in BlockClosure>>on:do:
> BlockClosure>>valueAsUnwindBlockFrom:
> BlockClosure>>ensure:
> BlockClosure>>on:do:
> MethodContext(Context)>>doPrimitive:receiver:numArgs:boundByMethod:
> MethodContext(Context)>>tryPrimitive:receiver:numArgs:boundByMethod:
> MethodContext(Context)>>runMethod:numArgs:contextClass:
> [] in MethodContext(Context)>>send:receiver:class:super:numArgs:
> MethodContext(Context)>>findMethod:class:ifFound:
> MethodContext(Context)>>send:receiver:class:super:numArgs:
> MethodContext(Context)>>send:numArgs:
> MethodContext(Context)>>sendNonImmediate:numArgs:
> optimized [] in InstructionStream
> class>>initializeXMisc:numberOfExtensions:combinationRule:
> MethodContext(InstructionStream)>>interpretNextInstructionFor:
> optimized [] in Context>>safelyInterpretNextInstructionFor:
> BlockClosure>>ensure:
> BlockClosure>>on:do:
> MethodContext(Context)>>safelyInterpretNextInstructionFor:
> optimized [] in Context>>step
> BlockClosure>>ensure:
> BlockClosure>>on:do:
> MethodContext(Context)>>step
> optimized [] in Context>>sendIntoBlockStartingWithCallee:
> BlockClosure>>ensure:
> MethodContext(Context)>>sendIntoBlockStartingWithCallee:
> BlockContext>>stepToCtxtWithSameParentAs:
> optimized [] in DebuggerService>>privateStepIntoBlock
> BlockClosure>>ensure:
> BlockClosure>>on:do:
> DebuggerService>>privateStepIntoBlock
> optimized [] in DebuggerService>>basicStepIntoBlock
> optimized [] in [] in [] in DebuggerService>>performDebugOperation:
> BlockClosure>>ensure:
> BlockClosure>>on:do:
> optimized [] in [] in DebuggerService>>performDebugOperation:
> BlockClosure>>ensure:
> BlockClosure>>on:do:
> optimized [] in DebuggerService>>performDebugOperation:
> optimized [] in [] in ProcessHandle>>performDebugOperation:
> BlockClosure>>ensure:
> BlockClosure>>on:do:
> optimized [] in ProcessHandle>>performDebugOperation:
>
>
>
> "self isLocked not"
>

--
Dennis Smith                         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              sip:[hidden email]
Canada         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP