Debugger acting up

Hi all,

I do not have a proper test case yet, but as I have seen it twice now I want to ask you guys if you have any problems with it.

In a recent moose 5.0 image with seaside and some other suff loaded, the page would not load. Interrupting the image showed that the debugger was lost in the following loop:

MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:

Originally it was a halt that caused the signal, and that should pop up the debugger, but instead of that it went into an infinite loop.

Now I see that building Pier3 development on a pharo2 image also seems to causes this loop. The root cause is also in the mail, so maybe this is just the size of the stack ...:
Startup Error: An attempt to use interactive tools detected, while in non-interactive mode
        Interactive Request: You are about to load new versions of the following packages
that have unsaved changes in the image:

 Grease-Tests-Pharo20-Core

If you continue, you will lose these changes:
NonInteractiveUIManager>>nonInteractiveWarning:
NonInteractiveUIManager>>nonInteractiveRequest:title:
NonInteractiveUIManager>>nonInteractiveRequest:
NonInteractiveUIManager>>confirm:trueChoice:falseChoice:cancelChoice:default:
MCMergeOrLoadWarning>>defaultAction
UndefinedObject>>handleSignal:

If anyone knows where this problem might come from, please put a mail on the mailing list.

Cheers,
Diego

Hi,

maybe related to something I found when using our locked-down images (no
Tools in ToolRegistry).

In SmalltalkImage>>openLog

FileStream fileNamed: Smalltalk tools debugger logFileName

was causing a loop since the default error handling ends up sending
#logDuring:, which
sends #openLog, causing an attempt to log an error (no debugger)...

For a quick workaround I changed to

openLog
 "This is a _private_ method,
 Because it really belongs to logging facility,
 we should delegate to it at some point "

 ^ ( FileStream fileNamed: Debugger logFileName )
  wantsLineEndConversion: true;
  setToEnd;
  yourself

though obviously not ideal having the direct reference to Debugger there.

Regards, Gary

----- Original Message -----
From: "Diego Lont" <[hidden email]>
To: "Pharo Development List" <[hidden email]>
Sent: Friday, March 21, 2014 2:32 PM
Subject: [Pharo-dev] Debugger acting up


Hi all,

I do not have a proper test case yet, but as I have seen it twice now I want
to ask you guys if you have any problems with it.

In a recent moose 5.0 image with seaside and some other suff loaded, the
page would not load. Interrupting the image showed that the debugger was
lost in the following loop:

MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
MethodContext(ContextPart)>>handleSignal:

Originally it was a halt that caused the signal, and that should pop up the
debugger, but instead of that it went into an infinite loop.

Now I see that building Pier3 development on a pharo2 image also seems to
causes this loop. The root cause is also in the mail, so maybe this is just
the size of the stack ...:
Startup Error: An attempt to use interactive tools detected, while in
non-interactive mode
Interactive Request: You are about to load new versions of the following
packages
that have unsaved changes in the image:

 Grease-Tests-Pharo20-Core

If you continue, you will lose these changes:
NonInteractiveUIManager>>nonInteractiveWarning:
NonInteractiveUIManager>>nonInteractiveRequest:title:
NonInteractiveUIManager>>nonInteractiveRequest:
NonInteractiveUIManager>>confirm:trueChoice:falseChoice:cancelChoice:default:
MCMergeOrLoadWarning>>defaultAction
UndefinedObject>>handleSignal:

If anyone knows where this problem might come from, please put a mail on the
mailing list.

Cheers,
Diego