Path: utzoo!utgpu!cs.utexas.edu!yale!mintaka!mit-eddie!wuarchive!zaphod.mps.ohio-state.edu!rpi!batcomputer!bat!eirik From: eirik@wonton.TN.Cornell.EDU (Eirik Fuller) Newsgroups: alt.hackers Subject: PTRACE_ATTACH Message-ID: Date: 25 Feb 91 22:49:55 GMT Sender: news@batcomputer.tn.cornell.edu Organization: Cornell Theory Center Lines: 36 Approved: the elf Nntp-Posting-Host: wonton.tn.cornell.edu I just ran out of memory in a GNU emacs window. Nearly anything I tried to do complained about tired memory ("Memory exhausted"). Unfortunately,, this included C-x k (kill-buffer). Since I was somewhat reluctant to close that window and open another, I decided to try to get it back into a working condition. I started another emacs window, for M-x gdb emacs, then used the gdb attach command on the process id of the tired emacs window. The error message came from the fact that new values from malloc were not valid lisp pointers, since they were outside the 24 bit range (yes, I know I should rebuild with two more bits; I've already done that on our "big" machines ...). The strings it was trying to allocate for any key bindings with prompts did not fit into the current_string_block. I noticed, however, that the contents of that variable included a piece of the first buffer I wanted to kill. So I contrived a useful lie, in which I claimed that the string currently in use was somewhat shorter than it really was. That left room for the new prompt strings, instead of calling malloc to make room for more. The truncated data that resulted from the lie was gone after I killed the buffer. So that emacs window is cheerfully humming along, with no more complaints about memory shortage. Of course, the very next thing I did was C-x C-b, followed by a bunch of d's and x's. This was not the first time I found gdb's attach command useful. Back when we were still running X11R3, my screen would occasionally freeze in the middle of drawing a line. One day I got sick of killing the server from elsewhere, so I instead attached to it with gdb. I found that it was stuck in some line-drawing function, apparently in some infinite loop; I used the debugger to return a bogus value from that function. I doubt the line got drawn, but my mouse started tracking again ... Brought to you by Super Global Mega Corp .com