Description of problem: This occured while emacs was starting, as far as I can tell. I cannot reproduce it. Version-Release number of selected component: emacs-24.3-11.fc19 Additional info: reporter: libreport-2.1.7 backtrace_rating: 4 cmdline: emacs crash_function: terminate_due_to_signal executable: /usr/bin/emacs-24.3 kernel: 3.11.3-201.fc19.x86_64 runlevel: N 5 type: CCpp uid: 1000 var_log_messages: Oct 10 14:42:10 penguin abrt[2917]: Saved core dump of pid 2373 (/usr/bin/emacs-24.3) to /var/tmp/abrt/ccpp-2013-10-10-14:42:09-2373 (50700288 bytes) Truncated backtrace: Thread no. 1 (10 frames) #1 terminate_due_to_signal at /usr/src/debug/emacs-24.3/src/emacs.c:344 #2 handle_fatal_signal at /usr/src/debug/emacs-24.3/src/sysdep.c:1638 #3 deliver_thread_signal at /usr/src/debug/emacs-24.3/src/sysdep.c:1614 #4 deliver_fatal_thread_signal at /usr/src/debug/emacs-24.3/src/sysdep.c:1650 #6 getenv at getenv.c:89 #7 _XkbGetCharset at XKBCvt.c:326 #8 XkbTranslateKeySym at XKBBind.c:588 #9 XLookupString at XKBBind.c:805 #10 lookup_string at imConv.c:148 #11 _XimLookupMBText at imConv.c:175
Created attachment 810859 [details] File: backtrace
Created attachment 810860 [details] File: cgroup
Created attachment 810861 [details] File: core_backtrace
Created attachment 810862 [details] File: dso_list
Created attachment 810863 [details] File: environ
Created attachment 810864 [details] File: limits
Created attachment 810865 [details] File: maps
Created attachment 810866 [details] File: open_fds
Created attachment 810867 [details] File: proc_pid_status
I was using the ESS mode for the R language for statistical computing to analyse the data from a small computer simulation. Other programs running in the meantime were evince and nautilus (which currently causes bug 998301 very often on my computer). I had a R live session opened in emacs, as well as a shell, a C++ source file (simulation), a text file (config) and a R script used to print a graph. I used C-c C-c to execute the script in the current R session (where the data was stored), to display the graph and print it to a SVG file. This worked without any issue, like it always did. I then modified the last line of the R script to print the same graph to PNG ("dev.print(png, "distance_chaos.png", width = 1024, height = 1024)") and hit C-c C-c. It worked but the graph was too large. I went back to the R live session and typed "?png" at the command line to display help about png files, which caused emacs to exit suddenly, as well as all processes running within it. I attempted to reproduce this bug but couldn't figure out how it happened. I started a new R session and the "?png" command worked as expected. I didn't notice anything else special before or after the bug occured. reporter: libreport-2.1.9 backtrace_rating: 4 cmdline: emacs crash_function: terminate_due_to_signal executable: /usr/bin/emacs-24.3 kernel: 3.11.6-200.fc19.x86_64 package: emacs-24.3-11.fc19 reason: Process /usr/bin/emacs-24.3 was killed by signal 11 (SIGSEGV) runlevel: N 5 type: CCpp uid: 1000
I believe it happened when switching syntax highlighting, but this happened a little while back. reporter: libreport-2.1.9 backtrace_rating: 3 cmdline: emacs ess_hci.c crash_function: terminate_due_to_signal executable: /usr/bin/emacs-24.3 kernel: 3.11.6-200.fc19.x86_64 package: emacs-24.3-11.fc19 reason: Process /usr/bin/emacs-24.3 was killed by signal 6 (SIGABRT) runlevel: N 5 type: CCpp uid: 1000
I was in the file chooser (for selecting files for the ediff tool), when I noticed that there was an old file in the list which should have been deleted. I went to a terminal window and removed that file from the shell. Immediately, the entire emacs process+file chooser crashed. reporter: libreport-2.1.9 backtrace_rating: 4 cmdline: emacs dnox-hbsg.py crash_function: terminate_due_to_signal executable: /usr/bin/emacs-24.3 kernel: 3.11.8-200.fc19.x86_64 package: emacs-24.3-11.fc19 reason: Process /usr/bin/emacs-24.3 was killed by signal 11 (SIGSEGV) runlevel: N 5 type: CCpp uid: 1000
This continues to occur with kernel version 3.11.10-200.fc19.x86_64 and emacs version emacs-24.3-11.fc19.x86_64. The problem occurred while emacs is starting, but then did not reoccur the second time emacs was started.
Hi, Mark from backtrace i see this: #6 __GI_getenv (name=0x3275f186da "KB_CHARSET", name@entry=0x3275f186d8 "_XKB_CHARSET") at getenv.c:89 ep_start = <error reading variable ep_start (Cannot access memory at address 0x22500000369)> I saw this "glitch" a few times before. This is almost never reproducible. Besides, this is a problem of glibc or package providing C standart library. But without reproducer unrepairable. Hello Jean-Loup Tastet, Solomon Peachy, oliver.org, not for the first time terminate_due_to_signal is called. core dump would tell me more (of course after reproducing your issue). Steps to create core with full backtrace information for emacs: $ cd /tmp download the latest emacs build from https://jchaloup.fedorapeople.org for your distribution and architecture (wget can be used). Should be always actual release in fedora + 1. $ wget https://jchaloup.fedorapeople.org/emacs-24.3-19.fc20.x86_64.rpm install downloaded rpm, release can vary # rpm -Uvh emacs-24.3-19.fc20.x86_64.rpm Then reproduce the issue and upload generated core. After reproducing, just run # yum distro-sync emacs *** This bug has been marked as a duplicate of bug 991073 ***
Jean-Loup Tastet, Solomon Peachy, oliver.org, if you manage to reproduce your issue, please, report a new bug. Thank you Regards and good luck Jan