Description of problem: I found today 20M of a core file from emacs dumped yesterday. After trying to recall what may cause that I believe that this may be an effect of terminating a desktop session with emacs still running. That seems to be supported by error_message=0x7fff96090640 "Connection lost to X server `:0.0'" from frame 69. OTOH I tried today to reproduce the problem and after a number of tries so far I failed. That could be some sort of a race on a termination. A backtrace produced by gdb after emacs-debuginfo was installed is attached. Please let me know if a core file is of any interest. Version-Release number of selected component (if applicable): emacs-22.1.50-4.fc9 How reproducible: I failed to repeat after five or six tries this core the way as describe above. OTOH sending SIGABRT to a running emacs process dumps core every time (with a suitable 'ulimit') although backtrace is then only fifteen frames deep. Still emacs frames look very similar to those in an attached backtrace. That was on x86_64 but I would be surprised to find that this is a requirement.
Created attachment 298165 [details] gdb backtrace from a core produced by emacs
(In reply to comment #0) > OTOH sending SIGABRT to a running emacs > process dumps core every time (with a suitable 'ulimit') ? That is exactly how it is supposed to work!
For example: $ ulimit -c unlimited $ sleep 20 & [1] 9314 $ kill -ABRT 9314 $ [1]+ Aborted (core dumped) sleep 20 $ file core.9314 core.9314: ELF 64-bit LSB core file AMD x86-64, version 1 (SYSV), SVR4-style, from 'sleep' This is not a bug in "sleep". This is what SIGABRT is for. Chip