Do you mind to share with us what is the cause of the problem? If it is too long to describe, then don't waste your time.
It's quite tricky but ok, I'll try it. It's actually a *great* example why Smalltalk is so much better than C/C++.
As you may know, I'm re-opening the standard output and error for redirecting everything from there into a file so that it can be shown upon Squeak exiting. For this, I created a temporary file and reopened the standard and error output. Now, the bug was that got the order wrong (*don't* ask me why ;-)) so that I re-opened the file before trying to get temporary file name. This results in actually *freeing* of the handle since the file could not be created. So far, the standard handle was just not there (btw, I only did this wrong with the stderr handle so all stuff going to stdout went ok).
Now comes the funny stuff: *Because* I had actually closed the standard handle, the system (e.g., the run-time library) felt free to re-use the resources associated with it. In other words, when a file was opened there was a certain chance that it would be stored in the place normally reserved for the standard handle. This *can* lead to all sorts of unforeseen effects but since most files are closed upon exiting the image there is usually no problem with it (and that's exactly why you could exit Squeak by using the desktop menu).
However, the order of operations when doing *particular* this update led to the effect that during fileIn of the update the changes file was stored in the place of the standard handle when you tried to exit through the close button. And then the cleanup goes wrong since it does not expect to have a *huge* error output.
So again, thanks for finding the "right" order of operation ;-)
That's it. Andreas
squeak-dev@lists.squeakfoundation.org