Version-Release number of selected component: emacs-24.3-13.fc20 Additional info: reporter: libreport-2.1.12 backtrace_rating: 4 cmdline: /usr/bin/emacs --daemon crash_function: count_size_as_multibyte executable: /usr/bin/emacs-24.3 kernel: 3.13.4-200.fc20.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 count_size_as_multibyte at /usr/src/debug/emacs-24.3/src/character.c:682 #1 concat at /usr/src/debug/emacs-24.3/src/fns.c:562 #2 exec_byte_code at /usr/src/debug/emacs-24.3/src/bytecode.c:1277 #3 funcall_lambda at /usr/src/debug/emacs-24.3/src/eval.c:3010 #4 Ffuncall at /usr/src/debug/emacs-24.3/src/eval.c:2839 #5 exec_byte_code at /usr/src/debug/emacs-24.3/src/bytecode.c:900 #6 funcall_lambda at /usr/src/debug/emacs-24.3/src/eval.c:3010 #7 Ffuncall at /usr/src/debug/emacs-24.3/src/eval.c:2839 #8 exec_byte_code at /usr/src/debug/emacs-24.3/src/bytecode.c:900 #9 eval_sub at /usr/src/debug/emacs-24.3/src/eval.c:2149
Created attachment 869995 [details] File: backtrace
Created attachment 869996 [details] File: cgroup
Created attachment 869997 [details] File: core_backtrace
Created attachment 869998 [details] File: dso_list
Created attachment 869999 [details] File: environ
Created attachment 870000 [details] File: exploitable
Created attachment 870001 [details] File: limits
Created attachment 870002 [details] File: maps
Created attachment 870003 [details] File: open_fds
Created attachment 870004 [details] File: proc_pid_status
Created attachment 870005 [details] File: var_log_messages
Hi, Jon, can you, please, give me more information about what you were doing in emacs at the moment of this issue? From backtrace I see you get out of adress space. SIGTERM signal (nb 15) was catched as well. Also a lot of "mark_object" function calls inside of emacs showing the currently evaluated lisp object was very big. Could be caused by consuming all the available memory. 1) Did you pressed CTRL+C during emacs run 2) What file was open (pdf,docs,...) or what you were viewing/working on? 3) Have you manage to reproduce the same issue? If so, can you give me as many steps as possible so I can simulate the same situation and to get more informations? 4) Any additional information is appreciated. Thank you in advance Regards Jan
Sorry, I can't remember exactly what happend. I use Emacs daily, so it could have been any number of things. I did not investigate the particular bug after submitting the trace. I do recall some issues in the past where Emacs would appear to lock up. I do not have a precise recipe, but it would happen using mercurial tools such as commit, rebase, and histedit. Each of these would spawn an Emacs frame (using emacsclient) and let me enter or alter text as a commit message. Sometimes, the mercurial prompt would appear to hang with the message "Waiting for Emacs...". On occassion, after the closing the frame, the mercurial prompt would not proceed. I may have hit CTRL+C to try to move ahead. On the other hand, if this looks like a memory consumption issue, the only files I may have opened to cause a large consumption of memory would be large MySQL dumps as SQL files. These typically slow Emacs to crawl and make the whole process unusable. I have since stopped opening files in this manner for that reason. I may have sent a kill signal to Emacs if this happened. If I hit this issue again, I'll try to be more observant about what happend and give details about what files were open. I am not removing NEEDINFO as I feel this information is probably insufficient to debug the trace. If you feel otherwsie, then please remove.
Thank you, Jon, for response. I will wait till you manage to hit the nail :).
I'm going to close this as I simply have no idea what happened. I'll re-open if this becomes easy to reproduce.
*** Bug 1214657 has been marked as a duplicate of this bug. ***