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


Ben Coman wrote:
Schwab,Wilhelm K wrote:
One snag: I'm still getting strangely broken images (won't open process browser or debugger) after trying to download some things. I have mirrored squeak source, BUT, some things (SIXX, ODBC) don't appear to have working configs, so I'm trying to grab the latest packages, and *that* might not be mirrored. I might need to specify the mirror server in my code to make them work.

Still, I don't get how simply asking MC to download something will permanently mar the image w/o my doing an explicit save. Does MC snapshot before/during an attempted load? It seems very misguided that an innocent attempt to load something can hobble an image??

One other crazy possibility: is killing a vm from the (Ubunutu) system monitor somehow not sufficient to clear what is running? Dumb question? Maybe, but I'm stumped. Any ideas?

Bill



________________________________________
From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of blake [dsblakewat...@gmail.com]
Sent: Thursday, February 09, 2012 2:58 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] 1.4 - better from Jenkins

I just downloaded the latest CogWin and Pharo 1.4 image and I got
"WARNING: Manufactured file handle detected!" at the bottom, and popup
full of startup errors.
A couple of days ago tried Pharo-1.4-14315 and with cogwin_r2522. I had the same warning, with a debugger showing "Error: Got startup errors"
in method SmalltalkImage snapshot:andQuit: "  at line:
   startupErrors isEmpty
       ifFalse: [ self error: 'Got startup errors ' ].
where startupErrors = an OrderedCollection(ShouldBeImplemented: #preferencesFolder should have been implemented in DosFileDirectory class)

So I thought I may as well try implementing DosFileDirectory>>preferencesFolder - which I've left as a comment on ISSUE 5255. <http://code.google.com/p/pharo/issues/detail?id=5255> A nice side effect of this was that all the "WARNING: Manufactured file handle detected!" went away. Reverting this change reintroduces the warnings.

cheers, -ben




Reply via email to