Bug 1071984

Summary: [abrt] emacs: count_size_as_multibyte(): emacs-24.3 killed by SIGSEGV
Product: [Fedora] Fedora Reporter: Jon Dufresne <jon.dufresne>
Component: emacsAssignee: Petr Hracek <phracek>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: jchaloup, jonathan.underwood, jon.dufresne, phracek, yukach
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/40ecf28d1e531c5384c06def5f4506289bd64b67
Whiteboard: abrt_hash:b6b2e78514c45efbf6058c18f5a13c9d44c15df0
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-04-30 16:21:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: exploitable
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Jon Dufresne 2014-03-03 15:52:53 UTC 
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
Comment 1 Jon Dufresne 2014-03-03 15:53:05 UTC 
Created attachment 869995 [details]
File: backtrace
Comment 2 Jon Dufresne 2014-03-03 15:53:07 UTC 
Created attachment 869996 [details]
File: cgroup
Comment 3 Jon Dufresne 2014-03-03 15:53:10 UTC 
Created attachment 869997 [details]
File: core_backtrace
Comment 4 Jon Dufresne 2014-03-03 15:53:11 UTC 
Created attachment 869998 [details]
File: dso_list
Comment 5 Jon Dufresne 2014-03-03 15:53:13 UTC 
Created attachment 869999 [details]
File: environ
Comment 6 Jon Dufresne 2014-03-03 15:53:17 UTC 
Created attachment 870000 [details]
File: exploitable
Comment 7 Jon Dufresne 2014-03-03 15:53:19 UTC 
Created attachment 870001 [details]
File: limits
Comment 8 Jon Dufresne 2014-03-03 15:53:20 UTC 
Created attachment 870002 [details]
File: maps
Comment 9 Jon Dufresne 2014-03-03 15:53:22 UTC 
Created attachment 870003 [details]
File: open_fds
Comment 10 Jon Dufresne 2014-03-03 15:53:26 UTC 
Created attachment 870004 [details]
File: proc_pid_status
Comment 11 Jon Dufresne 2014-03-03 15:53:27 UTC 
Created attachment 870005 [details]
File: var_log_messages
Comment 12 Jan Chaloupka 2014-04-28 11:46:29 UTC 
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
Comment 13 Jon Dufresne 2014-04-28 16:54:18 UTC 
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.
Comment 15 Jan Chaloupka 2014-04-30 12:41:49 UTC 
Thank you, Jon, for response. I will wait till you manage to hit the nail :).
Comment 16 Jon Dufresne 2014-04-30 16:21:42 UTC 
I'm going to close this as I simply have no idea what happened. I'll re-open if this becomes easy to reproduce.
Comment 17 Jan Chaloupka 2015-04-23 11:04:06 UTC 
*** Bug 1214657 has been marked as a duplicate of this bug. ***