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" <[email protected]>
To: "Pharo Development List" <[email protected]>
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:
[0mNonInteractiveUIManager>>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
