Hello all, This reminds me of some things that evolved in Dolphin, at least some of which Pharo has already. Logging of unhandled exceptions is important, and Pharo does it. However, it appears to replace debug.log with every error. There should be an easy way to get it to accumulate errors. Imagine monitoring the performance of a server or embedded system; one cares not only that a backup or update failed, but that it fails often, etc. The log needs to be thread safe. Much of the content of debug.log looks like it overlaps with what Dolphin puts in a "crash dump." IIRC, it was my idealism combined with Blair McGlashan's deep understanding of VMs that lead to the latter. I noted that unhandled Smalltalk exceptions were logged, but the more rare crash that made it all the way to the OS was completely silent in the logs. Blair created the dump and added an interesting twist, which was to allow a crash dump to be fired off without actually needing the crash. That meant that the detailed (and verbose) stack dump with data was created on a crash, and could be triggered as needed. The error log did not carry the additional data, and was therefore small enough to accumulate. Chris Uppal created a wonderful tool called Ghoul to display crash dumps in a debugger-like view. It shows code from the current image (which might differ from the code that created the dump - but that's life), and inspects data from the dump. Highly recommended! There were some snags with format changes over time. Some of it involved decimal/hex confusion over offsets written by the VM, and possibly spotting the beginning and end of individual dump records. BTW, the latter problem might be something that I am recalling from my own logging adventures; certainly I had that problem at times, but Ghoul might have too. I'm not sure, but will mention it to be one the safe side. Finally, I noted that while there was a way to break out of a hang in the IDE, there was no way to get information from a deployed executable that managed to hang. I modified my runtime session managers [*]to hook into control-break, and logged text-only stack traces on all non-dead processes. That allowed me to see deadlocks that showed up rarely. I have not looked in a while, but the pieces of doing the same thing in Squeak/Pharo exist, perhaps with some cosmetic defects in the spacing between callstacks. The default "show me the callstack" should dump all stacks, not just the active process. FWIW. Bill [*] session managers are those wonderful Dolphin concepts that allow a Smalltalk image to know when it's been loaded, letting it (among other things) initialize sockets on its own, etc. Lesser artist borrow, great artists steal - sorry, I'll try to stop nagging :) -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Rueger Sent: Saturday, August 01, 2009 8:37 AM To: Pharo-project@lists.gforge.inria.fr; dale.henrichs@gemstone.com Subject: Re: [Pharo-project] Custom user Interrupt handling Dale Henrichs wrote:
The class UserInterruptHandler is tantalizingly close, however, there is no obvious way to insinuate myself as an interested party....It's pretty much hard-wired to open a debugger on the interrupted process....
Just write your own class (e.g. subclass UserInterruptHandler) and replace the handler (unregister the current one and register your own). That's why I designed it the way it is :-) michael _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project