Re: Empty debugger - Pharo 5.0

I just got this problem again and I did noticed this time that I got an "error during termination" that I "Abandoned" before realizing that I should have recorded the stack ...

I've saved the image if anyone is interested in doing a post mortem...

Dale

I've gotten to a point where I get a single frame in a debugger ...
Here's a healthy halt run from a playground:



and here's the empty halt:



When I open a debugger I only see the one frame .. this is not quite right ... The other thing that happens in this mode is that halts don't halt the ui process and I can end up with a screen full of halt if I put a halt in a loop or worse I end up with infinite errors, because the UI process is not halted (at least that's my current hypothesis) ...

There is a UI process and I have saved and restarted the image at this point:


In a helathy image the UI process stack looks very similar, but I do notice that I've got an OSSubprocess child watcher in the healthy image and it is missing from the sick image:



It appears that I create this problem when I terminate a debugger that was brought up in an ensure block ... once I've done this the image becomes completely unusable (for development and debugging) and I have to create a new image from scratch ...

I'm hoping that someone can give me the secret formula for repairing things ...

Is the UI process instance cached somewhere and when I nuke the process running ensure blocks the debugger's ensure block doesn't run or some such thing?

I'll follow this route as I investigate ... any help would be appreciated as this makes debugging very time consuming

Dale

I brought up the image again (fortunately it wasn't saved in a bad state) I got the "Unwind error during termination" ... unfortunately the copy stack to clipboard menu item (in the artfully hidden menu) doesn't copy the whole stack so I've attached two pngs with the rest of the stack :

TDHaltNotification>>defaultRuntimeError
TDHaltNotification(TDNotification)>>defaultAction
UndefinedObject>>handleSignal:
Context>>handleSignal:
Context>>handleSignal:
Context>>handleSignal:
Context>>handleSignal:
Context>>handleSignal:
TDHaltNotification(Exception)>>signal
GsGci32xErrSType>>asLocalObjectFor:
GsGci32xErrSType>>asLocalObjectFor:ifNotConverted:
GsGciSession>>executeStringFetchBytes:rawBuffer:
Tugrik>>performOperationOnServer:withArgs:
Tugrik>>queryOperation:opCode:collectionBytes:offset:chunkSize:dataBytes:
QueryOperation>>performTugrikOperationOn:
Tugrik>>cursorQuery:
TugrikCursor>>execute
Tugrik>>queryOne:
Tugrik>>command:database:
TugrikDatabase>>command:
TugrikDatabase>>drop
[ :db | db drop ] in VOTugrikRepositoryResolver(VOMongoRepositoryResolver)>>basicDropDatabase in Block: [ :db | db drop ]
[ ^ aBlock value: db ] in VOTugrikSessionPool>>withDatabase: in Block: [ ^ aBlock value: db ]
BlockClosure>>ensure:
VOTugrikSessionPool>>withDatabase:
VOTugrikRepositoryResolver(VOMongoRepositoryResolver)>>basicDropDatabase
[ self basicDropDatabase ] in VOTugrikRepositoryResolver(VOMongoRepositoryResolver)>>dropDatabase in Block: [ self basicDropDatabase ]
BlockClosure>>on:do:
VOMongoExecuteStrategy>>execute
VOTugrikRepositoryResolver(VOMongoRepositoryResolver)>>execute:

With this debugger open, a `self halt` gives me a proper debugger ..... and when I close the debugger (drum roll please) the bug does not repeat ...

Trying a second time, abandoning does not reproduce the error, but rerunning the test that causes the original problem it does not terminate because the ensure block form the previous test did not run and the image is blocked on a shared queue and produces the following stack:

Monitor>>exitAndWaitInQueue:maxMilliseconds:
Monitor>>waitWhile:inQueue:maxMilliseconds:
Monitor>>waitWhile:for:maxMilliseconds:
Monitor>>waitWhile:for:
Monitor>>waitWhile:
[ monitor waitWhile: [ items isEmpty ].
items removeFirst ] in SharedQueue>>next in Block: [ monitor waitWhile: [ items isEmpty ]....
[ self enter.
aBlock value ] in Monitor>>critical: in Block: [ self enter....
BlockClosure>>ensure:
Monitor>>critical:
SharedQueue>>next
[ session := sessions next.
activeSessions add: (self ensureConnected: session) ] in VOTugrikSessionPool>>obtainSession in Block: [ session := sessions next....
BlockClosure>>ensure:
[ owner := activeProcess.
aBlock
    ensure: [ owner := nil ] ] in Mutex>>critical: in Block: [ owner := activeProcess....
[ caught := true.
self wait.
blockValue := mutuallyExcludedBlock value ] in Semaphore>>critical: in Block: [ caught := true....
BlockClosure>>ensure:
Semaphore>>critical:
Mutex>>critical:
VOTugrikSessionPool>>obtainSession
VOTugrikSessionPool(VOSessionPool)>>withSession:
VOTugrikRepositoryResolver>>onServerDo:serializeBlock:
VOTugrikRepository>>onServerDo:
BlockClosure>>voyageDoOnServer:
VOTugrikClassMappingTest>>testServerSideMaterializationSerialization
VOTugrikClassMappingTest(TestCase)>>performTest
[ self setUp.
self performTest ] in VOTugrikClassMappingTest(TestCase)>>runCase in Block: [ self setUp....
BlockClosure>>ensure:
VOTugrikClassMappingTest(TestCase)>>runCase
[ aTestCase announce: TestCaseStarted withResult: self.
aTestCase runCase.
aTestCase announce: TestCaseEnded withResult: self.
self addPass: aTestCase ] in TestResult>>runCaseForDebug: in Block: [ aTestCase announce: TestCaseStarted withResult: ...etc...
BlockClosure>>on:do:
TestResult>>runCaseForDebug:

which again does not produce the whole stack (another png attached to finish the job) .. then closing that debugger which hangs again so interrupt again and close that debugger (of course I neglected to get the stack for that one, because I wanted to see if the bug would reproduce ... and it does:(

so I get got this stack (incomplete yet again) and I did not make a png of the full stack because I'm tired of re-arranging all of the windows:

Monitor>>exitAndWaitInQueue:maxMilliseconds:
Monitor>>waitWhile:inQueue:maxMilliseconds:
Monitor>>waitWhile:for:maxMilliseconds:
Monitor>>waitWhile:for:
Monitor>>waitWhile:
[ monitor waitWhile: [ items isEmpty ].
items removeFirst ] in SharedQueue>>next in Block: [ monitor waitWhile: [ items isEmpty ]....
[ self enter.
aBlock value ] in Monitor>>critical: in Block: [ self enter....
BlockClosure>>ensure:
Monitor>>critical:
SharedQueue>>next
[ session := sessions next.
activeSessions add: (self ensureConnected: session) ] in VOTugrikSessionPool>>obtainSession in Block: [ session := sessions next....
BlockClosure>>ensure:
[ owner := activeProcess.
aBlock
    ensure: [ owner := nil ] ] in Mutex>>critical: in Block: [ owner := activeProcess....
[ caught := true.
self wait.
blockValue := mutuallyExcludedBlock value ] in Semaphore>>critical: in Block: [ caught := true....
BlockClosure>>ensure:
Semaphore>>critical:
Mutex>>critical:
VOTugrikSessionPool>>obtainSession
VOTugrikSessionPool>>withDatabase:
VOTugrikRepositoryResolver(VOMongoRepositoryResolver)>>basicDropDatabase
[ self basicDropDatabase ] in VOTugrikRepositoryResolver(VOMongoRepositoryResolver)>>dropDatabase in Block: [ self basicDropDatabase ]
BlockClosure>>on:do:
VOMongoExecuteStrategy>>execute
VOTugrikRepositoryResolver(VOMongoRepositoryResolver)>>execute:
VOTugrikRepositoryResolver(VOMongoRepositoryResolver)>>dropDatabase
VOTugrikRepository(VOMongoRepository)>>dropDatabase
[ self repository
    dropDatabase;
    flush ] in VOTugrikClassMappingTest(VOTugrikTest)>>tearDown in Block: [ self repository...
BlockClosure>>on:do:
VOTugrikClassMappingTest(VOTugrikTest)>>tearDown
[ self tearDown.
self cleanUpInstanceVariables ] in VOTugrikClassMappingTest(TestCase)>>runCase in Block: [ self tearDown....

... at this point I have lost track of how many times I have to interrupt and close the process ... I assume that I am interrupting at the "wrong spot" ...

at the end of the day, the interesting thing is that once whatever bad thing happens it results in the Empty Debuggers from then on out even after stopping and restarting as well as resaving and restarting ... so perhaps the best outcoem would be for someone to figure out what's wrong the image (that I have saved) and then work backward form that as to what might be causing the problem ...

Dale

I just got this problem again and I did noticed this time that I got an "error during termination" that I "Abandoned" before realizing that I should have recorded the stack ...

I've saved the image if anyone is interested in doing a post mortem...

Dale

On 7/21/16 10:33 AM, Dale Henrichs wrote:

I've gotten to a point where I get a single frame in a debugger ...
Here's a healthy halt run from a playground:



and here's the empty halt:



When I open a debugger I only see the one frame .. this is not quite right ... The other thing that happens in this mode is that halts don't halt the ui process and I can end up with a screen full of halt if I put a halt in a loop or worse I end up with infinite errors, because the UI process is not halted (at least that's my current hypothesis) ...

There is a UI process and I have saved and restarted the image at this point:


In a helathy image the UI process stack looks very similar, but I do notice that I've got an OSSubprocess child watcher in the healthy image and it is missing from the sick image:



It appears that I create this problem when I terminate a debugger that was brought up in an ensure block ... once I've done this the image becomes completely unusable (for development and debugging) and I have to create a new image from scratch ...

I'm hoping that someone can give me the secret formula for repairing things ...

Is the UI process instance cached somewhere and when I nuke the process running ensure blocks the debugger's ensure block doesn't run or some such thing?

I'll follow this route as I investigate ... any help would be appreciated as this makes debugging very time consuming

Dale