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-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Henrik Johansen [henrik.s.johansen@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