The error I reported here should not affect your using a breakpoint
#snapshot:andQuit in to debug this. Just avoid clicking <restart> in
the debugger for #snapshot:andQuit:
For your problem with the debugger, here is how I would go about it.
1. Check if any failures occur with TestRunner on ToolsTest-Debugger?
If any of them do fail (for example #testBasic), then use that as an
observation point to help isolate the problem.
2. Automate the loading of additional code using the new preferences
feature. After each step check whether #testBasic now fails. This
hopefully makes it reproducible and facilitates divide and conquer to
isolate which code is interfering with the debugger.
A possible startup script (pseudocode)
Transcript open.
Transcript crShow: 'Loading A failures = '
Load the code for A
Transcript show: ( DebuggerTest run: #testBasic ) failures size
Transcript crShow: 'Loading B failures = '
Load the code for B
Transcript show: ( DebuggerTest run: #testBasic ) failures size
...etc
Execute `StartupLoader example` to generate a template startup script.
Unzip a fresh image. Seed the local package cache from a previous
image. Run the image.
3. Set Debugger>>logDebuggerStackToFile and see if anything spits out
(note I haven't used this myself - just saw it in the code)
cheers, -ben
Schwab,Wilhelm K wrote:
Sig,
Has there been any decision/update on this? One good suggestion to get to the
bottom of my problem is to set a breakpoint in the snapshot code. But, I
currently have little faith that this will reveal an offender, because one of
the early symptoms of my images going bad is that debuggers will no longer open.
If reverting a change or whatever else fixes this, it could be a big help in
finding my problem, if not (via event sensor) a fix to it.
Bill
________________________________________
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] on behalf of Henrik Johansen
[henrik.s.johan...@veloxit.no]
Sent: Monday, February 13, 2012 6:55 AM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Debugger hanging... was Re: 1.4 - better from
Jenkins
On Feb 10, 2012, at 6:42 PM, Ben Coman wrote:
While I was working towards implementing DosFileDirectory>>preferencesFolder &
>>preferencesGeneralFolder
I was stepping through: SmalltalkImage>>snapshot:andQuit: did a: <Restart>
and then stepped down to: Cursor write show
at which point the debugger hung the image.
Now I guess theres an equal chance this is not really an issue as something
"special" might be happening here straddling the save point. Just thought I
would report it for review.
To reproduce on non-Windows you could probably set preferencesFolder &
preferencesGeneralFolder on your platform to self shouldBeImplemented and proceed
from the debugger that comes up.
SmalltalkImage>>snapshot: save andQuit: quit
| snapshotResult resuming startupErrors |
Object flushDependents.
Object flushEvents.
self addSnapshotRecord: save andQuit: quit.
self processShutDownList: quit.
Cursor write show. <--------Image Hangs Here after a <Restart> of the
method while debugging following a resume..
cheers, -ben
IIRC, the InputEventSensor is deregistered as part of shutdown, if so, that
would indeed lead to a non-responsive image at that point. (In the sense that
the thing that processes input is no longer there)
Cheers,
Henry
