Ralph wrote: >.. >>>> The email is not saved, but has got to be in memory > somewhere. >>>> How do I find the temp file? I would really like to keep > the >>>> text of that email. >.. > Since I know the PID of the email composer (and since I know > that Mozilla itself is *not* hosed), would it be possible to > send it some kind of signal to save its contents? I can't > seem to do anything from :0. And I can't load Mozilla on :1 > because of the lock file, but aside from that, but I don't > seem to have much restriction from :1. How does one send a > "Save" signal to the Mozilla email composer process?
Ralph, I have been trying to think of a way for you to get your data, and I haven't got a good recipe. (But see para #3, at end) 1. As far as I know there is no signal that (generically) tells a program to save its work. I suppose any given program could be written to do that, but I can find no documentation that mozilla does that. I tried a couple of tests with thunderbird, and nothing seems to force a save. That thought strikes me as a great idea, but it doesn't seem to have been written that way <sigh>. 2. Some programs have some kind of autosave feature so you don't lose (as much) work if (say) the power fails, but there does not seem to be such a feature in thunderbird (or, I suspect, mozilla mail), so there is not likely to be a file on your system that contains your work -- unless you explicitly did a save while composing your message (ie, putting it in the drafts folder). Sorry 3. Examining the memory of the process seems to me like the most promising possibility. Although I haven't been able to find a quick answer of how, here's what I found so far: cat /proc/PID/numa_maps or maybe cat /proc/PID/numa_maps | grep anon Tells what memory blocks are used by process with the given pid, 'PID'. For exxample, on my (64-bit) system, I get addresses like 2aaab28ea000 default anon=1 dirty=1 N0=1 On my 64bit system, memory blocks are 8K long (0x2000), but if you have a 32bit system, I think the blocks are 4K long (0x1000) gdb attach PID > dump memory /tmp/file1 0x2aaab28ea000 0x2aaab28eb000 this dumps a 4K block to a file '/tmp/file1' If you see adjacent memory blocks, I guess you can dump those adjacent blocks in a single file, but evidently you can't ask for a dump that spans memory not owned by the process. Now, I don't know any way to make this more painless or to script it. Maybe someone with better debug skills will jump in? It seems that there _ought_ to be a way to dump all memory, but I sure don't know what it is. In the end, if the value of the data is significantly short of priceless, you may just need to accept its loss and do your best at reconstructing or re-obtaining it Regards, ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
