Path: utzoo!utgpu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!batcomputer!bat!eirik From: eirik@wonton.TN.Cornell.EDU (Eirik Fuller) Newsgroups: alt.hackers Subject: Re: PTRACE_ATTACH Message-ID: Date: 26 Feb 91 07:29:56 GMT References: Sender: news@batcomputer.tn.cornell.edu Organization: Cornell Theory Center Lines: 23 Approved: of course In-Reply-To: eirik@wonton.TN.Cornell.EDU's message of 25 Feb 91 17:49:55 Nntp-Posting-Host: wonton.tn.cornell.edu In my last posting, I described my use of gdb's attach command to salvage a tired emacs window. Kids, don't try this at home! Seriously, though, the emacs process dumped core soon thereafter. It was a useful hack in that I was able to save some buffers before it died, but a complete hack would have cleaned up the mess I made in current_string_block before the garbage collector tripped over it. Gee, I can't wait ... time to start visiting core files until I run out of memory again ... :-) ObHack: I fixed the debugger as a result of the emacs core dump. It seems it dumped core trying to read the core dump. Then it dumped core trying to read its own core dump. That was simple enough to fix; a function argument needed an &. So the emacs core dump turned out to be useful after all; I'm not sure when I would have noticed that the debugger couldn't read core files otherwise. What? That's too tame for an ObHack? How about the use of conditional debugger breakpoints with commands as a means of patching code, as an alternative to recompilation? Must be smalltalk that got me into that bad habit ... :-) Brought to you by Super Global Mega Corp .com