* bug#7098: Emacs24 crash with segmentation fault @ 2010-09-24 17:53 Thierry Volpiatto 2010-09-24 18:18 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 48+ messages in thread From: Thierry Volpiatto @ 2010-09-24 17:53 UTC (permalink / raw) To: 7098 Hi, emacs24 become unusable as it crash several times a day always with same error. ,---- | Program received signal SIGSEGV, Segmentation fault. | 0x0817dbad in mark_object () `---- -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-24 17:53 bug#7098: Emacs24 crash with segmentation fault Thierry Volpiatto @ 2010-09-24 18:18 ` Eli Zaretskii 2010-09-24 19:14 ` Eli Zaretskii 2010-09-24 19:23 ` Thierry Volpiatto 2010-12-06 20:39 ` Chong Yidong 2010-12-18 9:16 ` Thierry Volpiatto 2 siblings, 2 replies; 48+ messages in thread From: Eli Zaretskii @ 2010-09-24 18:18 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: 7098 > From: Thierry Volpiatto <thierry.volpiatto@gmail.com> > Date: Fri, 24 Sep 2010 19:53:28 +0200 > Cc: > > Hi, > emacs24 become unusable as it crash several times a day always with same > error. > > ,---- > | Program received signal SIGSEGV, Segmentation fault. > | 0x0817dbad in mark_object () > `---- Could you please "bzr bisect" to find which revision is the culprit? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-24 18:18 ` Eli Zaretskii @ 2010-09-24 19:14 ` Eli Zaretskii 2010-09-24 19:32 ` Thierry Volpiatto 2010-09-27 8:54 ` Thierry Volpiatto 2010-09-24 19:23 ` Thierry Volpiatto 1 sibling, 2 replies; 48+ messages in thread From: Eli Zaretskii @ 2010-09-24 19:14 UTC (permalink / raw) To: thierry.volpiatto, 7098 > Date: Fri, 24 Sep 2010 20:18:50 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 7098@debbugs.gnu.org > > > ,---- > > | Program received signal SIGSEGV, Segmentation fault. > > | 0x0817dbad in mark_object () > > `---- > > Could you please "bzr bisect" to find which revision is the culprit? Also, what are your system-configuration and system-configuration-options? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-24 19:14 ` Eli Zaretskii @ 2010-09-24 19:32 ` Thierry Volpiatto 2010-09-24 19:48 ` Eli Zaretskii 2010-09-27 8:54 ` Thierry Volpiatto 1 sibling, 1 reply; 48+ messages in thread From: Thierry Volpiatto @ 2010-09-24 19:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7098 Eli Zaretskii <eliz@gnu.org> writes: >> Date: Fri, 24 Sep 2010 20:18:50 +0200 >> From: Eli Zaretskii <eliz@gnu.org> >> Cc: 7098@debbugs.gnu.org >> >> > ,---- >> > | Program received signal SIGSEGV, Segmentation fault. >> > | 0x0817dbad in mark_object () >> > `---- >> >> Could you please "bzr bisect" to find which revision is the culprit? > > Also, what are your system-configuration and I use gentoo Linux tux 2.6.35-tuxonice-r3 #1 SMP Sat Sep 18 09:41:19 CEST 2010 i686 Genuine Intel(R) CPU T2130 @ 1.86GHz GenuineIntel GNU/Linux > system-configuration-options? Which configuration options? -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-24 19:32 ` Thierry Volpiatto @ 2010-09-24 19:48 ` Eli Zaretskii 0 siblings, 0 replies; 48+ messages in thread From: Eli Zaretskii @ 2010-09-24 19:48 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: 7098 > From: Thierry Volpiatto <thierry.volpiatto@gmail.com> > Cc: 7098@debbugs.gnu.org > Date: Fri, 24 Sep 2010 21:32:26 +0200 > > > Also, what are your system-configuration and > I use gentoo > Linux tux 2.6.35-tuxonice-r3 #1 SMP Sat Sep 18 09:41:19 CEST 2010 i686 Genuine Intel(R) CPU T2130 @ 1.86GHz GenuineIntel GNU/Linux > > > system-configuration-options? > Which configuration options? system-configuration and system-configuration-options are Lisp variables. Evaluate them inside Emacs and tell what are their values. TIA ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-24 19:14 ` Eli Zaretskii 2010-09-24 19:32 ` Thierry Volpiatto @ 2010-09-27 8:54 ` Thierry Volpiatto 2010-09-27 10:53 ` Eli Zaretskii 1 sibling, 1 reply; 48+ messages in thread From: Thierry Volpiatto @ 2010-09-27 8:54 UTC (permalink / raw) To: bug-gnu-emacs Eli Zaretskii <eliz@gnu.org> writes: >> Date: Fri, 24 Sep 2010 20:18:50 +0200 >> From: Eli Zaretskii <eliz@gnu.org> >> Cc: 7098@debbugs.gnu.org >> >> > ,---- >> > | Program received signal SIGSEGV, Segmentation fault. >> > | 0x0817dbad in mark_object () >> > `---- >> >> Could you please "bzr bisect" to find which revision is the culprit? > > Also, what are your system-configuration and > system-configuration-options? Sorry for late reply here, i just forget. ,----[ system-configuration ] | "i686-pc-linux-gnu" `---- ,----[ system-configuration-options ] | " '--prefix=/usr' '--build=i686-pc-linux-gnu' | '--host=i686-pc-linux-gnu' '--mandir=/usr/share/man' | '--infodir=/usr/share/info' '--datadir=/usr/share' | '--sysconfdir=/etc' '--localstatedir=/var/lib' | '--program-suffix=-emacs-24' '--infodir=/usr/share/info/emacs-24' | '--with-crt-dir=/usr/lib' '--without-compress-info' '--with-sound' | '--with-x' '--without-gconf' '--without-xml2' | '--without-toolkit-scroll-bars' '--with-gif' | '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff' | '--with-xpm' '--without-imagemagick' '--with-xft' | '--without-libotf' '--without-m17n-flt' '--with-x-toolkit=gtk' | '--without-hesiod' '--without-kerberos' '--without-kerberos5' | '--with-gpm' '--with-dbus' 'build_alias=i686-pc-linux-gnu' | 'host_alias=i686-pc-linux-gnu' 'CFLAGS=-march=i686 -pipe -O2' | 'LDFLAGS=-Wl,-O1 -Wl,--as-needed'" `---- So actually before crashing with segfault, i crash immediately when i launch gnus with: ,---- | Program received signal SIGABRT, Aborted. | 0xffffe424 in __kernel_vsyscall () `---- NOTE that Emacs23 development branch work fine here without crashing. -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-27 8:54 ` Thierry Volpiatto @ 2010-09-27 10:53 ` Eli Zaretskii 2010-09-27 12:43 ` Thierry Volpiatto 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2010-09-27 10:53 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: bug-gnu-emacs > From: Thierry Volpiatto <thierry.volpiatto@gmail.com> > Date: Mon, 27 Sep 2010 10:54:25 +0200 > Cc: > > So actually before crashing with segfault, i crash immediately when i > launch gnus with: > > ,---- > | Program received signal SIGABRT, Aborted. > | 0xffffe424 in __kernel_vsyscall () > `---- Can you post more levels of backtrace? I'd like to see if that happens in GC as well. Thanks. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-27 10:53 ` Eli Zaretskii @ 2010-09-27 12:43 ` Thierry Volpiatto 2010-09-27 13:56 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Thierry Volpiatto @ 2010-09-27 12:43 UTC (permalink / raw) To: bug-gnu-emacs Eli Zaretskii <eliz@gnu.org> writes: >> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >> Date: Mon, 27 Sep 2010 10:54:25 +0200 >> Cc: >> >> So actually before crashing with segfault, i crash immediately when i >> launch gnus with: >> >> ,---- >> | Program received signal SIGABRT, Aborted. >> | 0xffffe424 in __kernel_vsyscall () >> `---- > > Can you post more levels of backtrace? I'd like to see if that > happens in GC as well. ,---- | Program received signal SIGABRT, Aborted. | 0xffffe424 in __kernel_vsyscall () | (gdb) bt full | #0 0xffffe424 in __kernel_vsyscall () | No symbol table info available. | #1 0xb7357726 in kill () from /lib/libc.so.6 | No symbol table info available. | #2 0x0812697b in abort () | No symbol table info available. | #3 0x081d5d06 in wait_reading_process_output () | No symbol table info available. | #4 0x08059ea0 in sit_for () | No symbol table info available. | #5 0x08135749 in read_char () | No symbol table info available. | #6 0x081366ac in read_key_sequence () | No symbol table info available. | #7 0x081387c2 in command_loop_1 () | No symbol table info available. | #8 0x08196251 in internal_condition_case () | No symbol table info available. | #9 0x08130e05 in command_loop_2 () | No symbol table info available. | #10 0x08196331 in internal_catch () | No symbol table info available. | #11 0x08130fb1 in command_loop () | No symbol table info available. | #12 0x0813133b in recursive_edit_1 () | No symbol table info available. | #13 0x08131462 in Frecursive_edit () | No symbol table info available. | #14 0x08127961 in main () | No symbol table info available. `---- Out of gdb output is: ,---- | Fatal error (6)Abandon `---- -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-27 12:43 ` Thierry Volpiatto @ 2010-09-27 13:56 ` Eli Zaretskii 2010-09-27 14:06 ` Thierry Volpiatto 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2010-09-27 13:56 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: bug-gnu-emacs > From: Thierry Volpiatto <thierry.volpiatto@gmail.com> > Date: Mon, 27 Sep 2010 14:43:30 +0200 > Cc: > > Eli Zaretskii <eliz@gnu.org> writes: > > Can you post more levels of backtrace? I'd like to see if that > > happens in GC as well. > > ,---- > | Program received signal SIGABRT, Aborted. > | 0xffffe424 in __kernel_vsyscall () > | (gdb) bt full > | #0 0xffffe424 in __kernel_vsyscall () > | No symbol table info available. > | #1 0xb7357726 in kill () from /lib/libc.so.6 > | No symbol table info available. > | #2 0x0812697b in abort () > | No symbol table info available. > | #3 0x081d5d06 in wait_reading_process_output () > | No symbol table info available. > | #4 0x08059ea0 in sit_for () > | No symbol table info available. > | #5 0x08135749 in read_char () > | No symbol table info available. > | #6 0x081366ac in read_key_sequence () Looks like an entirely different kind of crash, and not related to GC. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-27 13:56 ` Eli Zaretskii @ 2010-09-27 14:06 ` Thierry Volpiatto 2010-09-27 15:43 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Thierry Volpiatto @ 2010-09-27 14:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: bug-gnu-emacs Eli Zaretskii <eliz@gnu.org> writes: >> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >> Date: Mon, 27 Sep 2010 14:43:30 +0200 >> Cc: >> >> Eli Zaretskii <eliz@gnu.org> writes: >> > Can you post more levels of backtrace? I'd like to see if that >> > happens in GC as well. >> >> ,---- >> | Program received signal SIGABRT, Aborted. >> | 0xffffe424 in __kernel_vsyscall () >> | (gdb) bt full >> | #0 0xffffe424 in __kernel_vsyscall () >> | No symbol table info available. >> | #1 0xb7357726 in kill () from /lib/libc.so.6 >> | No symbol table info available. >> | #2 0x0812697b in abort () >> | No symbol table info available. >> | #3 0x081d5d06 in wait_reading_process_output () >> | No symbol table info available. >> | #4 0x08059ea0 in sit_for () >> | No symbol table info available. >> | #5 0x08135749 in read_char () >> | No symbol table info available. >> | #6 0x081366ac in read_key_sequence () > > Looks like an entirely different kind of crash, and not related to GC. Yes, that only when launching gnus. Maybe we should open a different bug. -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-27 14:06 ` Thierry Volpiatto @ 2010-09-27 15:43 ` Eli Zaretskii 2010-09-28 7:48 ` Thierry Volpiatto 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2010-09-27 15:43 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: bug-gnu-emacs > From: Thierry Volpiatto <thierry.volpiatto@gmail.com> > Cc: bug-gnu-emacs@gnu.org > Date: Mon, 27 Sep 2010 16:06:49 +0200 > > > Looks like an entirely different kind of crash, and not related to GC. > Yes, that only when launching gnus. > Maybe we should open a different bug. Probably a good idea. Please try to provide a traceback from a non-stripped binary, though, otherwise it's hard to reason about the possible causes. Thanks. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-27 15:43 ` Eli Zaretskii @ 2010-09-28 7:48 ` Thierry Volpiatto 0 siblings, 0 replies; 48+ messages in thread From: Thierry Volpiatto @ 2010-09-28 7:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: bug-gnu-emacs Eli Zaretskii <eliz@gnu.org> writes: >> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >> Cc: bug-gnu-emacs@gnu.org >> Date: Mon, 27 Sep 2010 16:06:49 +0200 >> >> > Looks like an entirely different kind of crash, and not related to GC. >> Yes, that only when launching gnus. >> Maybe we should open a different bug. > > Probably a good idea. Please try to provide a traceback from a > non-stripped binary, though, otherwise it's hard to reason about the > possible causes. Ok i open another bug. -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-24 18:18 ` Eli Zaretskii 2010-09-24 19:14 ` Eli Zaretskii @ 2010-09-24 19:23 ` Thierry Volpiatto 2010-09-24 19:36 ` Eli Zaretskii 1 sibling, 1 reply; 48+ messages in thread From: Thierry Volpiatto @ 2010-09-24 19:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7098 Eli Zaretskii <eliz@gnu.org> writes: >> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >> Date: Fri, 24 Sep 2010 19:53:28 +0200 >> Cc: >> >> Hi, >> emacs24 become unusable as it crash several times a day always with same >> error. >> >> ,---- >> | Program received signal SIGSEGV, Segmentation fault. >> | 0x0817dbad in mark_object () >> `---- > > Could you please "bzr bisect" to find which revision is the culprit? This command doesn't exists here (bzr 2.2.0) bzr: ERROR: unknown command "bisect" ,----[ bzr log ] | revno: 101596 | committer: Juanma Barranquero <lekktu@gmail.com> | branch nick: trunk | timestamp: Fri 2010-09-24 20:04:26 +0200 | message: | src/ChangeLog: Fix typo and remove duplicate info. `---- Note that emacs crash also with precedents versions also since one week about. -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-24 19:23 ` Thierry Volpiatto @ 2010-09-24 19:36 ` Eli Zaretskii 2010-09-24 19:58 ` Thierry Volpiatto 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2010-09-24 19:36 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: 7098 > From: Thierry Volpiatto <thierry.volpiatto@gmail.com> > Cc: 7098@debbugs.gnu.org > Date: Fri, 24 Sep 2010 21:23:09 +0200 > > > Could you please "bzr bisect" to find which revision is the culprit? > This command doesn't exists here (bzr 2.2.0) > > bzr: ERROR: unknown command "bisect" Sorry, I forgot to mention that you will need to install the bisect plugin, if you don't have it already. > Note that emacs crash also with precedents versions also since one week > about. So it is crashing on your system for the last week or so, is that right? Is it possible for you to find the last version which did not crash (or the first one that did)? "bzr bisect" makes this easier, but you could do this by hand as well, using "bzr revert -r". TIA ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-24 19:36 ` Eli Zaretskii @ 2010-09-24 19:58 ` Thierry Volpiatto 2010-09-24 20:14 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Thierry Volpiatto @ 2010-09-24 19:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7098 Eli Zaretskii <eliz@gnu.org> writes: >> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >> Cc: 7098@debbugs.gnu.org >> Date: Fri, 24 Sep 2010 21:23:09 +0200 >> >> > Could you please "bzr bisect" to find which revision is the culprit? >> This command doesn't exists here (bzr 2.2.0) >> >> bzr: ERROR: unknown command "bisect" > > Sorry, I forgot to mention that you will need to install the bisect > plugin, if you don't have it already. Ah! ok, i don't have this plugin and don't know how to install it. >> Note that emacs crash also with precedents versions also since one week >> about. > > So it is crashing on your system for the last week or so, is that > right? Yes > Is it possible for you to find the last version which did not > crash (or the first one that did)? "bzr bisect" makes this easier, > but you could do this by hand as well, using "bzr revert -r". It will be difficult because i don't build emacs myself actually, i use the gentoo package of Emacs-vcs. However, i will build an emacs from git tomorrow and try to downgrade until i find a working version. It could be long though as the crash appear at anytime, not necessarily on costly operations. -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-24 19:58 ` Thierry Volpiatto @ 2010-09-24 20:14 ` Eli Zaretskii 2010-09-25 7:40 ` Thierry Volpiatto 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2010-09-24 20:14 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: 7098 > From: Thierry Volpiatto <thierry.volpiatto@gmail.com> > Cc: 7098@debbugs.gnu.org > Date: Fri, 24 Sep 2010 21:58:36 +0200 > > However, i will build an emacs from git tomorrow and try to downgrade > until i find a working version. Thank you. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-24 20:14 ` Eli Zaretskii @ 2010-09-25 7:40 ` Thierry Volpiatto 2010-09-25 8:10 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Thierry Volpiatto @ 2010-09-25 7:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7098 Eli Zaretskii <eliz@gnu.org> writes: >> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >> Cc: 7098@debbugs.gnu.org >> Date: Fri, 24 Sep 2010 21:58:36 +0200 >> >> However, i will build an emacs from git tomorrow and try to downgrade >> until i find a working version. > > Thank you. I build a new emacs from: ,---- | commit de05ee3f1862edbd14741c4022377992efa1c6e6 | Commit: Stefan Monnier <monnier@iro.umontreal.ca> | CommitDate: Tue Sep 21 15:09:22 2010 +0200 | | * lisp/newcomment.el (comment-normalize-vars): Better test validity of | comment-end-skip. `---- It work fine a long time but finish by crashing also just moving down with arrow keys in the git log buffer. But with better debug infos, i hope this will help you: ,---- | Program received signal SIGSEGV, Segmentation fault. | 0x0817ddb5 in mark_object (arg=268415134) at alloc.c:5493 | 5493 if (XMISCANY (obj)->gcmarkbit) `---- And without gdb: *** glibc detected *** emacs-dev: free(): invalid next size (normal): 0x0aa917f8 *** ======= Backtrace: ========= /lib/libc.so.6(+0x6b861)[0xb6843861] /lib/libc.so.6(+0x6d0c8)[0xb68450c8] /lib/libc.so.6(cfree+0x6d)[0xb68481ad] emacs-dev[0x817ed31] emacs-dev[0x81824fa] emacs-dev[0x8196ad8] emacs-dev[0x8197007] emacs-dev[0x819725d] emacs-dev[0x818bcd6] emacs-dev[0x8197007] emacs-dev[0x819725d] emacs-dev[0x8199a09] emacs-dev[0x8197007] emacs-dev[0x819725d] emacs-dev[0x81974d9] emacs-dev[0x8197703] emacs-dev[0x81ceaa1] emacs-dev[0x81973e4] emacs-dev[0x8197703] emacs-dev[0x81ceaa1] emacs-dev[0x81973e4] emacs-dev[0x8197703] emacs-dev[0x81ceaa1] emacs-dev[0x81973e4] emacs-dev[0x8197703] emacs-dev[0x8198bb9] emacs-dev[0x8197976] emacs-dev[0x81ceaa1] emacs-dev[0x8196f78] emacs-dev[0x8199712] emacs-dev[0x81cdceb] emacs-dev[0x81973e4] emacs-dev[0x8197703] emacs-dev[0x81ceaa1] emacs-dev[0x81973e4] emacs-dev[0x8197703] emacs-dev[0x8195c9e] emacs-dev[0x8087e02] emacs-dev[0x8087e75] emacs-dev[0x8087f64] emacs-dev[0x807beff] emacs-dev[0x8084a46] emacs-dev[0x8081272] emacs-dev[0x80859b1] emacs-dev[0x808d3eb] emacs-dev[0x80906a5] emacs-dev[0x8092bb6] emacs-dev[0x8195e97] emacs-dev[0x80949ee] emacs-dev[0x8134120] emacs-dev[0x813641c] emacs-dev[0x8138512] emacs-dev[0x8195f91] emacs-dev[0x8130b85] emacs-dev[0x8196071] emacs-dev[0x8130d31] emacs-dev[0x81310bb] emacs-dev[0x81311e2] emacs-dev[0x8127651] /lib/libc.so.6(__libc_start_main+0xe6)[0xb67eebb6] emacs-dev[0x8056e61] ======= Memory map: ======== 08048000-08215000 r-xp 00000000 08:07 6146965 /home/thierry/tmp/emacs-git/src/emacs 08215000-08216000 r--p 001cc000 08:07 6146965 /home/thierry/tmp/emacs-git/src/emacs 08216000-087cd000 rw-p 001cd000 08:07 6146965 /home/thierry/tmp/emacs-git/src/emacs 087cd000-0ae3b000 rw-p 00000000 00:00 0 [heap] b5500000-b5521000 rw-p 00000000 00:00 0 b5521000-b5600000 ---p 00000000 00:00 0 b56b8000-b56d4000 r-xp 00000000 08:05 1002254 /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libgcc_s.so.1 b56d4000-b56d5000 r--p 0001b000 08:05 1002254 /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libgcc_s.so.1 b56d5000-b56d6000 rw-p 0001c000 08:05 1002254 /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libgcc_s.so.1 b56ee000-b5727000 r--p 00000000 08:05 980574 /usr/share/fonts/dejavu/DejaVuSansMono-Oblique.ttf b5727000-b5750000 rw-p 00000000 00:00 0 b5758000-b5e49000 rw-p 00000000 00:00 0 b5e49000-b5ea2000 rw-p 00000000 00:00 0 b5ea2000-b5ecf000 rw-p 00000000 00:00 0 b5ed6000-b5ee7000 rw-p 00000000 00:00 0 b5ee7000-b5f29000 rw-p 00000000 00:00 0 b5f39000-b5f84000 rw-p 00000000 00:00 0 b5f84000-b5fc2000 rw-p 00000000 00:00 0 b5fc2000-b5fc7000 r-xp 00000000 08:03 1126182 /lib/libnss_dns-2.11.2.so b5fc7000-b5fc8000 r--p 00004000 08:03 1126182 /lib/libnss_dns-2.11.2.so b5fc8000-b5fc9000 rw-p 00005000 08:03 1126182 /lib/libnss_dns-2.11.2.so b5fc9000-b6018000 r--p 00000000 08:05 986084 /usr/share/fonts/dejavu/DejaVuSansMono.ttf b6018000-b60bf000 r--p 00000000 08:05 986360 /usr/share/fonts/dejavu/DejaVuSans.ttf b60bf000-b60f6000 r--p 00000000 08:05 980548 /usr/share/fonts/dejavu/DejaVuSansMono-BoldOblique.ttf b60f6000-b6156000 rw-s 00000000 00:04 6258688 /SYSV00000000 (deleted) b6156000-b6179000 r--p 00000000 08:05 800249 /usr/share/locale/fr/LC_MESSAGES/libc.mo b6179000-b617a000 r-xp 00000000 08:05 702447 /usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.so b617a000-b617b000 r--p 00000000 08:05 702447 /usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.so b617b000-b617c000 rw-p 00001000 08:05 702447 /usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.so b617d000-b61c8000 r--p 00000000 08:05 985963 /usr/share/fonts/dejavu/DejaVuSansMono-Bold.ttf b61c8000-b61d9000 r--p 00000000 08:05 32862 /usr/share/locale/fr/LC_MESSAGES/GConf2.mo b61d9000-b61df000 r--s 00000000 08:06 66589 /var/cache/fontconfig/87f5e051180a7a75f16eb6fe7dbd3749-le32d4.cache-3 b61df000-b61e5000 r--s 00000000 08:06 66856 /var/cache/fontconfig/4460665c0f3e88acdd4c85aa2f409b99-le32d4.cache-3 b61e5000-b61f5000 r--s 00000000 08:06 66840 /var/cache/fontconfig/8d4af663993b81a124ee82e610bb31f9-le32d4.cache-3 b61f5000-b61f9000 r--s 00000000 08:06 66790 /var/cache/fontconfig/a336a40326b5f097d6a660e43ed65741-le32d4.cache-3 b61f9000-b61fb000 r--s 00000000 08:06 65779 /var/cache/fontconfig/5a8e70faeac692eefe28f2b44727cf4d-le32d4.cache-3 b61fb000-b6208000 r--s 00000000 08:06 65556 /var/cache/fontconfig/221fd1126b80b777db535aea535e87ba-le32d4.cache-3 b6208000-b620f000 r--s 00000000 08:06 66610 /var/cache/fontconfig/12b26b760a24f8b4feb03ad48a333a72-le32d4.cache-3 b620f000-b6222000 r--s 00000000 08:06 66015 /var/cache/fontconfig/4b5cf4386f1cde02a336ba961b4ac82d-le32d4.cache-3 b6222000-b6225000 r--s 00000000 08:06 66012 /var/cache/fontconfig/d3169a704c6df42fa91819104f3eb94b-le32d4.cache-3 b6225000-b622a000 r--s 00000000 08:06 65969 /var/cache/fontconfig/d62e99ef547d1d24cdb1bd22ec1a2976-le32d4.cache-3 b622a000-b622d000 r--s 00000000 08:06 65851 /var/cache/fontconfig/f6b893a7224233d96cb72fd88691c0b4-le32d4.cache-3 b622d000-b6232000 r--s 00000000 08:06 65761 /var/cache/fontconfig/f349e9996a5320f6dd491cedd2b1f964-le32d4.cache-3 b6232000-b6273000 r--s 00000000 08:06 65759 /var/cache/fontconfig/17090aa38d5c6f09fb8c5c354938f1d7-le32d4.cache-3 b6273000-b62b4000 r--s 00000000 08:06 65676 /var/cache/fontconfig/df311e82a1a24c41a75c2c930223552e-le32d4.cache-3 b62b4000-b62de000 r--p 00000000 08:05 799918 /usr/share/locale/fr/LC_MESSAGES/gtk20-properties.mo b62de000-b62e5000 r--s 00000000 08:05 721789 /usr/lib/gconv/gconv-modules.cache b62e5000-b62ee000 r-xp 00000000 08:03 1126276 /lib/libnss_nis-2.11.2.so b62ee000-b62ef000 r--p 00008000 08:03 1126276 /lib/libnss_nis-2.11.2.so b62ef000-b62f0000 rw-p 00009000 08:03 1126276 /lib/libnss_nis-2.11.2.so b62f0000-b6303000 r-xp 00000000 08:03 1126243 /lib/libnsl-2.11.2.so b6303000-b6304000 r--p 00012000 08:03 1126243 /lib/libnsl-2.11.2.so b6304000-b6305000 rw-p 00013000 08:03 1126243 /lib/libnsl-2.11.2.so b6305000-b6307000 rw-p 00000000 00:00 0 b6307000-b630d000 r-xp 00000000 08:03 1126292 /lib/libnss_compat-2.11.2.so b630d000-b630e000 r--p 00006000 08:03 1126292 /lib/libnss_compat-2.11.2.so b630e000-b630f000 rw-p 00007000 08:03 1126292 /lib/libnss_compat-2.11.2.so b630f000-b6319000 r-xp 00000000 08:03 1126290 /lib/libnss_files-2.11.2.so b6319000-b631a000 r--p 00009000 08:03 1126290 /lib/libnss_files-2.11.2.so b631a000-b631b000 rw-p 0000a000 08:03 1126290 /lib/libnss_files-2.11.2.so b631b000-b6490000 r--p 00000000 08:05 721792 /usr/lib/locale/locale-archive b6490000-b6494000 rw-p 00000000 00:00 0 b6494000-b64a5000 r-xp 00000000 08:03 1126682 /lib/libbz2.so.1.0.6 b64a5000-b64a6000 r--p 00010000 08:03 1126682 /lib/libbz2.so.1.0.6 b64a6000-b64a7000 rw-p 00011000 08:03 1126682 /lib/libbz2.so.1.0.6 b64a7000-b64b1000 r-xp 00000000 08:05 703058 /usr/lib/libdrm.so.2.4.0 b64b1000-b64b2000 r--p 00009000 08:05 703058 /usr/lib/libdrm.so.2.4.0Fatal error (6)^CErreur de segmentation t I will try to go down in the trunk to find a working version. -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-25 7:40 ` Thierry Volpiatto @ 2010-09-25 8:10 ` Eli Zaretskii 2010-09-25 8:23 ` Thierry Volpiatto 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2010-09-25 8:10 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: 7098 > From: Thierry Volpiatto <thierry.volpiatto@gmail.com> > Cc: 7098@debbugs.gnu.org > Date: Sat, 25 Sep 2010 09:40:55 +0200 > > I will try to go down in the trunk to find a working version. Thanks. Crashes in GC are hard to track down (etc/DEBUG has some guidance, but it needs some proficiency to actually follow through). Knowing which commit caused the problem makes it much easier to find the culprit. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-25 8:10 ` Eli Zaretskii @ 2010-09-25 8:23 ` Thierry Volpiatto 2010-09-25 9:25 ` Juanma Barranquero 0 siblings, 1 reply; 48+ messages in thread From: Thierry Volpiatto @ 2010-09-25 8:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 7098 Eli Zaretskii <eliz@gnu.org> writes: >> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >> Cc: 7098@debbugs.gnu.org >> Date: Sat, 25 Sep 2010 09:40:55 +0200 >> >> I will try to go down in the trunk to find a working version. > > Thanks. Crashes in GC are hard to track down (etc/DEBUG has some > guidance, but it needs some proficiency to actually follow through). > Knowing which commit caused the problem makes it much easier to find > the culprit. Yes, i will try first to find a day, i am actually on last commit of 20 sept, if it crash i will go on last commit of 19 and so on. Once i find the good commit it should be easy to track all commits of one day, maybe with git-bisect between good and last bad. -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-25 8:23 ` Thierry Volpiatto @ 2010-09-25 9:25 ` Juanma Barranquero 2010-09-25 9:35 ` Thierry Volpiatto 0 siblings, 1 reply; 48+ messages in thread From: Juanma Barranquero @ 2010-09-25 9:25 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: 7098 On Sat, Sep 25, 2010 at 10:23, Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote: > Yes, i will try first to find a day, i am actually on last commit of 20 > sept, if it crash i will go on last commit of 19 and so on. > Once i find the good commit it should be easy to track all commits of > one day, maybe with git-bisect between good and last bad. A couple of questions: - Are you using GCC 4.4.0 or later? - Does the crash happen both with optimized and non-optimized builds? I ask because I've been getting garbage collection crashes for a while with non-optimized builds built with GCC 4.4.0, 4.5.0, 4.5.1, etc. The problem disappears if I revert back to GCC 3.4.5 or build with optimizations. Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-25 9:25 ` Juanma Barranquero @ 2010-09-25 9:35 ` Thierry Volpiatto 2010-09-25 11:13 ` Juanma Barranquero 0 siblings, 1 reply; 48+ messages in thread From: Thierry Volpiatto @ 2010-09-25 9:35 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 7098 Juanma Barranquero <lekktu@gmail.com> writes: > On Sat, Sep 25, 2010 at 10:23, Thierry Volpiatto > <thierry.volpiatto@gmail.com> wrote: > >> Yes, i will try first to find a day, i am actually on last commit of 20 >> sept, if it crash i will go on last commit of 19 and so on. >> Once i find the good commit it should be easy to track all commits of >> one day, maybe with git-bisect between good and last bad. > > A couple of questions: > > - Are you using GCC 4.4.0 or later? 4.4.3 > - Does the crash happen both with optimized and non-optimized builds? What is optimized and non-optimized builds? > I ask because I've been getting garbage collection crashes for a while > with non-optimized builds built with GCC 4.4.0, 4.5.0, 4.5.1, etc. The > problem disappears if I revert back to GCC 3.4.5 or build with > optimizations. > > Juanma > -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-25 9:35 ` Thierry Volpiatto @ 2010-09-25 11:13 ` Juanma Barranquero 2010-09-25 11:39 ` Thierry Volpiatto 0 siblings, 1 reply; 48+ messages in thread From: Juanma Barranquero @ 2010-09-25 11:13 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: 7098 On Sat, Sep 25, 2010 at 11:35, Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote: > What is optimized and non-optimized builds? Basically, building Emacs with optimization options for the compiler (typically -O2 for GCC) or not. Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-25 11:13 ` Juanma Barranquero @ 2010-09-25 11:39 ` Thierry Volpiatto 2010-09-25 11:59 ` Eli Zaretskii 2010-09-25 12:01 ` Juanma Barranquero 0 siblings, 2 replies; 48+ messages in thread From: Thierry Volpiatto @ 2010-09-25 11:39 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 7098 Juanma Barranquero <lekktu@gmail.com> writes: > On Sat, Sep 25, 2010 at 11:35, Thierry Volpiatto > <thierry.volpiatto@gmail.com> wrote: > >> What is optimized and non-optimized builds? > > Basically, building Emacs with optimization options for the compiler > (typically -O2 for GCC) or not. Ah! ok, i use -j3 in my make.conf according to gentoo recommendations for my processor i686 Genuine Intel(R) CPU T2130 @ 1.86GHz GenuineIntel. So from another build of emacs ,---- | commit 00bbf32677ebca75b47e89a7f0511da2257654d2 | Commit: Juanma Barranquero <lekktu@gmail.com> | CommitDate: Tue Sep 21 14:49:59 2010 +0200 | | src/makefile.w32-in ($(BLD)/sysdep.$(O)): Update dependencies. `---- i crash with again this error in alloc.c: ,---- | Program received signal SIGSEGV, Segmentation fault. | 0x0817513d in mark_object (arg=142015006) at alloc.c:5487 | 5487 if (VECTOR_MARKED_P (XVECTOR (obj))) `---- before it was ,---- | Program received signal SIGSEGV, Segmentation fault. | 0x0817ddb5 in mark_object (arg=268415134) at alloc.c:5493 | 5493 if (XMISCANY (obj)->gcmarkbit) `---- I can crash at everytime now using the same command that recurse through a big tree and match regexp in file (like rgrep but all lisp). This same command work fine in 23.2 (on same conditions of course). But as i said in precedent posts, i can crash also doing simple things e.g next-line in any buffer. -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-25 11:39 ` Thierry Volpiatto @ 2010-09-25 11:59 ` Eli Zaretskii 2010-09-25 12:32 ` Thierry Volpiatto 2010-09-25 21:26 ` Thierry Volpiatto 2010-09-25 12:01 ` Juanma Barranquero 1 sibling, 2 replies; 48+ messages in thread From: Eli Zaretskii @ 2010-09-25 11:59 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: lekktu, 7098 > From: Thierry Volpiatto <thierry.volpiatto@gmail.com> > Cc: Eli Zaretskii <eliz@gnu.org>, 7098@debbugs.gnu.org > Date: Sat, 25 Sep 2010 13:39:05 +0200 > > I can crash at everytime now using the same command that recurse > through a big tree and match regexp in file (like rgrep but all lisp). Is it possible to post that command and any data it uses here? Then perhaps others could join the effort of hunting down this bug. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-25 11:59 ` Eli Zaretskii @ 2010-09-25 12:32 ` Thierry Volpiatto 2010-09-25 21:26 ` Thierry Volpiatto 1 sibling, 0 replies; 48+ messages in thread From: Thierry Volpiatto @ 2010-09-25 12:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, 7098 [-- Attachment #1: Type: text/plain, Size: 1014 bytes --] Eli Zaretskii <eliz@gnu.org> writes: >> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >> Cc: Eli Zaretskii <eliz@gnu.org>, 7098@debbugs.gnu.org >> Date: Sat, 25 Sep 2010 13:39:05 +0200 >> >> I can crash at everytime now using the same command that recurse >> through a big tree and match regexp in file (like rgrep but all lisp). > > Is it possible to post that command and any data it uses here? Then > perhaps others could join the effort of hunting down this bug. > Yes sure, no dependencies needed, just load and use M-x traverse-deep-rfind on a big but reasonable directory (it is not rgrep, it's slow). The test i do take 172s here when it success. Use a regexp for "only" e.g .*\.el$ or nothing to stress more emacs. But i think using anything else to generate a lot of activity in Emacs should do the same. e.g using many tools at the same time. A good point is i couldn't crash Emacs23.2 at this game :-) -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 [-- Attachment #2: traverselisp.el --] [-- Type: application/emacs-lisp, Size: 39361 bytes --] ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-25 11:59 ` Eli Zaretskii 2010-09-25 12:32 ` Thierry Volpiatto @ 2010-09-25 21:26 ` Thierry Volpiatto 2010-09-26 5:25 ` Thierry Volpiatto 1 sibling, 1 reply; 48+ messages in thread From: Thierry Volpiatto @ 2010-09-25 21:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, 7098 Eli Zaretskii <eliz@gnu.org> writes: >> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >> Cc: Eli Zaretskii <eliz@gnu.org>, 7098@debbugs.gnu.org >> Date: Sat, 25 Sep 2010 13:39:05 +0200 >> >> I can crash at everytime now using the same command that recurse >> through a big tree and match regexp in file (like rgrep but all lisp). > > Is it possible to post that command and any data it uses here? Then > perhaps others could join the effort of hunting down this bug. > After stepping slowly with git-bisect from: ,---- | commit a05743b1752bb83d85e16ccaaff80f53dac3f986 | Commit: Stefan Monnier <monnier@iro.umontreal.ca> | CommitDate: Sun Sep 19 11:49:21 2010 +0200 | | * lisp/emacs-lisp/float-sup.el (float-pi): New name for `pi'. | (float-e): New name for `e'. | (degrees-to-radians, radians-to-degrees): | * lisp/calendar/solar.el (solar-longitude): | * lisp/calculator.el (calculator-registers, calculator-funcall): | * lisp/textmodes/artist.el (artist-spray-random-points): | * lisp/play/bubbles.el (bubbles--initialize-images): Use new names. `---- I end up here: ,---- | thierry@~/tmp/emacs-git-tip $ git-bisect good | 8e6f7306e47e2244a1c80fb933485fe42efe29b6 is the first bad commit | commit 8e6f7306e47e2244a1c80fb933485fe42efe29b6 | Author: Ari Roponen <ari.roponen@gmail.com> | Date: Tue Sep 21 21:33:59 2010 +0200 | | * doc.c (Fsnarf_documentation): Use memmove instead of memcpy as | the regions may overlap. | | :040000 040000 4806164fd8ce2b3de31292d002fd23bb2fcc3fed 587564f837cc8526b0e5c94df936c54f1136579d M src `---- Hope that help. -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-25 21:26 ` Thierry Volpiatto @ 2010-09-26 5:25 ` Thierry Volpiatto 0 siblings, 0 replies; 48+ messages in thread From: Thierry Volpiatto @ 2010-09-26 5:25 UTC (permalink / raw) To: bug-gnu-emacs [-- Attachment #1: Type: text/plain, Size: 2397 bytes --] Thierry Volpiatto <thierry.volpiatto@gmail.com> writes: > Eli Zaretskii <eliz@gnu.org> writes: > >>> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >>> Cc: Eli Zaretskii <eliz@gnu.org>, 7098@debbugs.gnu.org >>> Date: Sat, 25 Sep 2010 13:39:05 +0200 >>> >>> I can crash at everytime now using the same command that recurse >>> through a big tree and match regexp in file (like rgrep but all lisp). >> >> Is it possible to post that command and any data it uses here? Then >> perhaps others could join the effort of hunting down this bug. >> > > After stepping slowly with git-bisect from: > > ,---- > | commit a05743b1752bb83d85e16ccaaff80f53dac3f986 > | Commit: Stefan Monnier <monnier@iro.umontreal.ca> > | CommitDate: Sun Sep 19 11:49:21 2010 +0200 > | > | * lisp/emacs-lisp/float-sup.el (float-pi): New name for `pi'. > | (float-e): New name for `e'. > | (degrees-to-radians, radians-to-degrees): > | * lisp/calendar/solar.el (solar-longitude): > | * lisp/calculator.el (calculator-registers, calculator-funcall): > | * lisp/textmodes/artist.el (artist-spray-random-points): > | * lisp/play/bubbles.el (bubbles--initialize-images): Use new names. > `---- > > I end up here: > > ,---- > | thierry@~/tmp/emacs-git-tip $ git-bisect good > | 8e6f7306e47e2244a1c80fb933485fe42efe29b6 is the first bad commit > | commit 8e6f7306e47e2244a1c80fb933485fe42efe29b6 > | Author: Ari Roponen <ari.roponen@gmail.com> > | Date: Tue Sep 21 21:33:59 2010 +0200 > | > | * doc.c (Fsnarf_documentation): Use memmove instead of memcpy as > | the regions may overlap. > | > | :040000 040000 4806164fd8ce2b3de31292d002fd23bb2fcc3fed 587564f837cc8526b0e5c94df936c54f1136579d M src > `---- > > Hope that help. Sorry it finish by crashing again: ,---- | Program received signal SIGSEGV, Segmentation fault. | 0x0817ddc5 in mark_object (arg=1634758445) at alloc.c:5351 | 5351 if (VECTOR_MARKED_P (XVECTOR (obj))) `---- I am on this commit: ,---- | commit 00bbf32677ebca75b47e89a7f0511da2257654d2 | Commit: Juanma Barranquero <lekktu@gmail.com> | CommitDate: Tue Sep 21 14:49:59 2010 +0200 | | src/makefile.w32-in ($(BLD)/sysdep.$(O)): Update dependencies. `---- I have to step down again. :-( I attach the backtrace here (bt full). -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 [-- Attachment #2: debug-emacs-bt-full.txt --] [-- Type: text/plain, Size: 45120 bytes --] #0 0x0817ddc5 in mark_object (arg=1634758445) at alloc.c:5351 obj = 1634758445 #1 0x0817de6d in mark_object (arg=271896950) at alloc.c:5556 ptr = 0x1034d170 obj = <value optimized out> #2 0x0817dea5 in mark_object (arg=271908866) at alloc.c:5449 ptr = 0x10350000 obj = <value optimized out> #3 0x0817e618 in mark_maybe_pointer () at alloc.c:4118 obj = 271908866 m = 0x61706f2d #4 mark_memory () at alloc.c:4168 p = <value optimized out> pp = 0xbfffd74c #5 mark_stack () at alloc.c:4401 j = {o = 0, j = {{__jmpbuf = {0, -1073763793, 158614800, -1073763992, 461545042, -887500995}, __mask_was_saved = 0, __saved_mask = {__val = {0, 138048128, 138634792, 3221203256, 135781997, 138405738, 77, 3221226518, 139653120, 139886173, 3221203240, 251, 138370776, 138048128, 275254944, 728, 2624551902, 139886173, 68, 3221226518, 138370048, 138909206, 158614800, 3221203272, 138202744, 138091072, 138271296, 3221203304, 135431558, 138383530, 159568672, 248}}}}} stack_grows_down_p = 0 end = 0xbfffe5d8 #6 0x081817ca in Fgarbage_collect () at alloc.c:4981 bind = <value optimized out> catch = <value optimized out> handler = <value optimized out> stack_top_variable = 16 '\020' i = <value optimized out> message_p = 0 total = {138059800, -1073763740, 2, 138500376, 156021074, -1073763444, -1073759444, 27} t1 = {tv_sec = 1285477260, tv_usec = 312229} t2 = {tv_sec = -1073763444, tv_usec = -1073763744} #7 0x081cea86 in Fbyte_code (bytestr=156206001, vector=157554693, maxdepth=16) at bytecode.c:724 v1 = <value optimized out> op = 5 stack = {pc = 0x9600b03 "\036", top = 0xbfffaa60, bottom = 0xbfffaa60, byte_string = 156206001, byte_string_start = 0x9600ad8 "\306\307\b\"\310\031\032\311\312!\210\313\v!\203\026", constants = 157554693, next = 0xbfffac24} top = 0xbfffaa60 result = <value optimized out> #8 0x081971f4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x5) at eval.c:3174 val = <value optimized out> syms_left = 138383530 next = <value optimized out> i = 2 optional = 0 rest = 1 #9 0x08197513 in Ffuncall (nargs=3, args=0xbfffabd0) at eval.c:3047 fun = 1634758445 original_fun = 156158474 funcar = <value optimized out> ---Type <return> to continue, or q <return> to quit--- numargs = 2 val = <value optimized out> backtrace = {next = 0xbfffacfc, function = 0xbfffabd0, args = 0xbfffabd4, nargs = 2, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #10 0x081ce801 in Fbyte_code (bytestr=156210793, vector=145852629, maxdepth=12) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x960097a "\207\302\t!\203\030", top = 0xbfffabd8, bottom = 0xbfffabd0, byte_string = 156210793, byte_string_start = 0x960096c "\b\203\017", constants = 145852629, next = 0xbfffada4} top = 0xbfffabd0 result = <value optimized out> #11 0x081971f4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x5) at eval.c:3174 val = <value optimized out> syms_left = 138383530 next = <value optimized out> i = 2 optional = 1 rest = 0 #12 0x08197513 in Ffuncall (nargs=3, args=0xbfffad40) at eval.c:3047 fun = 1634758445 original_fun = 157063458 funcar = <value optimized out> numargs = 2 val = <value optimized out> backtrace = {next = 0xbfffae7c, function = 0xbfffad40, args = 0xbfffad44, nargs = 2, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #13 0x081ce801 in Fbyte_code (bytestr=154944009, vector=153836309, maxdepth=20) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x95e21aa "\211\024\207", top = 0xbfffad48, bottom = 0xbfffad40, byte_string = 154944009, byte_string_start = 0x95e2180 "\305\301!\210\306\307\310\b\"\206\017", constants = 153836309, next = 0xbfffaf14} top = 0xbfffad40 result = <value optimized out> #14 0x081971f4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x5) at eval.c:3174 val = <value optimized out> syms_left = 138383530 next = <value optimized out> i = 1 optional = 0 rest = 0 #15 0x08197513 in Ffuncall (nargs=2, args=0xbfffaec0) at eval.c:3047 fun = 1634758445 original_fun = 155744914 funcar = <value optimized out> numargs = 1 val = <value optimized out> backtrace = {next = 0xbfffafec, function = 0xbfffaec0, args = 0xbfffaec4, nargs = 1, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> ---Type <return> to continue, or q <return> to quit--- #16 0x081ce801 in Fbyte_code (bytestr=154947473, vector=153835005, maxdepth=8) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x95fb38b "\207", top = 0xbfffaec4, bottom = 0xbfffaec0, byte_string = 154947473, byte_string_start = 0x95fb374 "\b \210\303\t!\210\304\n!\210\305 \203\023", constants = 153835005, next = 0xbfffb084} top = 0xbfffaec0 result = <value optimized out> #17 0x081971f4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x5) at eval.c:3174 val = <value optimized out> syms_left = 138383530 next = <value optimized out> i = 0 optional = 35 rest = 35 #18 0x08197513 in Ffuncall (nargs=1, args=0xbfffb030) at eval.c:3047 fun = 1634758445 original_fun = 153835149 funcar = <value optimized out> numargs = 0 val = <value optimized out> backtrace = {next = 0xbfffb15c, function = 0xbfffb030, args = 0xbfffb034, nargs = 0, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #19 0x081ce801 in Fbyte_code (bytestr=154947697, vector=153835461, maxdepth=16) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x95fb36b ",)\207", top = 0xbfffb030, bottom = 0xbfffb030, byte_string = 154947697, byte_string_start = 0x95fb338 "\304\305 !\206\n", constants = 153835461, next = 0xbfffb1f4} top = 0xbfffb030 result = <value optimized out> #20 0x081971f4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x5) at eval.c:3174 val = <value optimized out> syms_left = 138383530 next = <value optimized out> i = 3 optional = 0 rest = 0 #21 0x08197513 in Ffuncall (nargs=4, args=0xbfffb1a0) at eval.c:3047 fun = 1634758445 original_fun = 155744866 funcar = <value optimized out> numargs = 3 val = <value optimized out> backtrace = {next = 0xbfffb2cc, function = 0xbfffb1a0, args = 0xbfffb1a4, nargs = 3, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #22 0x081ce801 in Fbyte_code (bytestr=154941873, vector=156824421, maxdepth=16) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x95e2279 "\207", top = 0xbfffb1ac, bottom = 0xbfffb1a0, byte_string = 154941873, byte_string_start = 0x95e2274 "\300\301\302\303#\207", constants = 156824421, next = 0xbfffb364} top = 0xbfffb1a0 ---Type <return> to continue, or q <return> to quit--- result = <value optimized out> #23 0x081971f4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x5) at eval.c:3174 val = <value optimized out> syms_left = 138383530 next = <value optimized out> i = 0 optional = -1073761624 rest = 135855942 #24 0x08197513 in Ffuncall (nargs=1, args=0xbfffb310) at eval.c:3047 fun = 1634758445 original_fun = 157610906 funcar = <value optimized out> numargs = 0 val = <value optimized out> backtrace = {next = 0xbfffb43c, function = 0xbfffb310, args = 0xbfffb314, nargs = 0, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #25 0x081ce801 in Fbyte_code (bytestr=155068169, vector=156349413, maxdepth=8) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x95faaab "\207", top = 0xbfffb310, bottom = 0xbfffb310, byte_string = 155068169, byte_string_start = 0x95faaa0 "eb\210\212\300\301!\210)\302 \207", constants = 156349413, next = 0xbfffb4e4} top = 0xbfffb310 result = <value optimized out> #26 0x081971f4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x5) at eval.c:3174 val = <value optimized out> syms_left = 138383530 next = <value optimized out> i = 0 optional = 0 rest = 0 #27 0x08197513 in Ffuncall (nargs=1, args=0xbfffb480) at eval.c:3047 fun = 1634758445 original_fun = 153842626 funcar = <value optimized out> numargs = 0 val = <value optimized out> backtrace = {next = 0xbfffb584, function = 0xbfffb480, args = 0xbfffb484, nargs = 0, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #28 0x081ce801 in Fbyte_code (bytestr=155071593, vector=154807893, maxdepth=28) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x95fa97e "\210\b\203\023", top = 0xbfffb480, bottom = 0xbfffb480, byte_string = 155071593, byte_string_start = 0x95fa978 "\303\304!\210\305 \210\b\203\023", constants = 154807893, next = 0xbfffb694} top = 0xbfffb480 result = <value optimized out> #29 0x08196d88 in Feval (form=155742070) at eval.c:2358 numargs = <value optimized out> args_left = 138383530 i = 3 ---Type <return> to continue, or q <return> to quit--- argvals = {155071593, 154807893, 28, 147000592, 146999632, 5, 156181685, -1073760700} fun = <value optimized out> val = <value optimized out> original_fun = 138508354 original_args = 155742062 funcar = <value optimized out> backtrace = {next = 0xbfffb76c, function = 0xbfffb59c, args = 0xbfffb564, nargs = 3, evalargs = 1 '\001', debug_on_exit = 0 '\000'} #30 0x0819706d in Fprogn (args=155741670) at eval.c:395 val = <value optimized out> #31 0x081950fe in unbind_to (count=54, value=138383530) at eval.c:3370 quitf = 138383530 #32 0x081ce7ae in Fbyte_code (bytestr=155072265, vector=154808013, maxdepth=16) at bytecode.c:701 op = 5 stack = {pc = 0x95fa95e "\207", top = 0xbfffb640, bottom = 0xbfffb640, byte_string = 155072265, byte_string_start = 0x95fa8fc "\306\307!\210\310\020\311 \210r\312 q\210\313\302!\210\t\022\314 \210\v\203 ", constants = 154808013, next = 0xbfffb804} top = 0xbfffb640 result = <value optimized out> #33 0x081971f4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x5) at eval.c:3174 val = <value optimized out> syms_left = 138383530 next = <value optimized out> i = 0 optional = 0 rest = 0 #34 0x08197513 in Ffuncall (nargs=1, args=0xbfffb7b0) at eval.c:3047 fun = 1634758445 original_fun = 156158066 funcar = <value optimized out> numargs = 0 val = <value optimized out> backtrace = {next = 0xbfffb8dc, function = 0xbfffb7b0, args = 0xbfffb7b4, nargs = 0, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #35 0x081ce801 in Fbyte_code (bytestr=155409201, vector=155748005, maxdepth=8) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x95f9c32 "\207", top = 0xbfffb7b0, bottom = 0xbfffb7b0, byte_string = 155409201, byte_string_start = 0x95f9c1c "\b\t\232?\205\026", constants = 155748005, next = 0xbfffb974} top = 0xbfffb7b0 result = <value optimized out> #36 0x081971f4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x5) at eval.c:3174 val = <value optimized out> syms_left = 138383530 next = <value optimized out> i = 1 optional = 0 rest = 0 #37 0x08197513 in Ffuncall (nargs=2, args=0xbfffb920) at eval.c:3047 fun = 1634758445 ---Type <return> to continue, or q <return> to quit--- original_fun = 155579946 funcar = <value optimized out> numargs = 1 val = <value optimized out> backtrace = {next = 0xbfffba14, function = 0xbfffb920, args = 0xbfffb924, nargs = 1, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #38 0x081ce801 in Fbyte_code (bytestr=155410121, vector=155747653, maxdepth=16) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x95f9b7a ",\207", top = 0xbfffb924, bottom = 0xbfffb920, byte_string = 155410121, byte_string_start = 0x95f9b64 "\302 \303\304\305 \"\030\031rƎ\307\310 \311\"\210\312\313 !,\207", constants = 155747653, next = 0xbfffbbb4} top = 0xbfffb920 result = <value optimized out> #39 0x08196d88 in Feval (form=155596894) at eval.c:2358 numargs = <value optimized out> args_left = 138383530 i = 3 argvals = {155410121, 155747653, 16, 0, 0, 0, 0, -1} fun = <value optimized out> val = <value optimized out> original_fun = 138508354 original_args = 155596886 funcar = <value optimized out> backtrace = {next = 0xbfffbc8c, function = 0xbfffba2c, args = 0xbfffb9f4, nargs = 3, evalargs = 1 '\001', debug_on_exit = 0 '\000'} #40 0x08199522 in internal_lisp_condition_case (var=138850010, bodyform=155596894, handlers=155118494) at eval.c:1407 val = <value optimized out> c = {tag = 138383530, val = 138383530, next = 0xbfffbef4, gcpro = 0x0, jmp = {{__jmpbuf = {155118488, 155747808, 48, -1073759416, 463937106, -671439043}, __mask_was_saved = 0, __saved_mask = {__val = {256, 0, 14680178, 14680178, 3086766068, 139698176, 3221207768, 3084085787, 139768312, 3221207756, 3221207768, 3082666595, 141771872, 3221207780, 16, 139747528, 138629288, 139886168, 3221207896, 3076325364, 3221208304, 160712224, 1, 138275976, 0, 139698176, 14680178, 138499210, 138499208, 138383530, 3221207880, 135889190}}}}, backlist = 0xbfffbc8c, handlerlist = 0xbfffbfbc, lisp_eval_depth = 16, pdlcount = 49, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0xbfffbbb4} h = {handler = 155118494, var = 138850010, chosen_clause = -1217196205, tag = 0xbfffba64, next = 0xbfffbfbc} #41 0x081cda4b in Fbyte_code (bytestr=155410217, vector=155747813, maxdepth=12) at bytecode.c:869 handlers = 136428128 body = <value optimized out> op = 5 stack = {pc = 0x95f9b5a ")\207", top = 0xbfffbb60, bottom = 0xbfffbb60, byte_string = 155410217, byte_string_start = 0x95f9b54 "\301\030\302\303ď)\207", constants = 155747813, next = 0xbfffbe04} top = 0xbfffbb60 result = <value optimized out> #42 0x081971f4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x5) at eval.c:3174 val = <value optimized out> syms_left = 138383530 next = <value optimized out> i = 0 optional = -1073759064 rest = 4096 #43 0x08197513 in Ffuncall (nargs=1, args=0xbfffbdb4) at eval.c:3047 ---Type <return> to continue, or q <return> to quit--- fun = 1634758445 original_fun = 155579898 funcar = <value optimized out> numargs = 0 val = <value optimized out> backtrace = {next = 0xbfffbd6c, function = 0xbfffbdb4, args = 0xbfffbdb8, nargs = 0, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #44 0x08198cdf in Fapply (nargs=2, args=0xbfffbdb4) at eval.c:2449 i = <value optimized out> numargs = 1634758445 spread_arg = 138383530 funcall_args = <value optimized out> fun = 155579898 retval = <value optimized out> sa_must_free = -1073758920 #45 0x08197786 in Ffuncall (nargs=3, args=0xbfffbdb0) at eval.c:2971 fun = <value optimized out> original_fun = 138500378 funcar = <value optimized out> numargs = 2 val = <value optimized out> backtrace = {next = 0xbfffbea4, function = 0xbfffbdb0, args = 0xbfffbdb4, nargs = 2, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #46 0x081ce801 in Fbyte_code (bytestr=137084921, vector=137084949, maxdepth=16) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x8345989 "\210)\301\207", top = 0xbfffbdb8, bottom = 0xbfffbdb0, byte_string = 137084921, byte_string_start = 0x8345980 "r\301\b\302H\b\303H\"\210)\301\207", constants = 137084949, next = 0xbfffc054} top = 0xbfffbdb0 result = <value optimized out> #47 0x08196d88 in Feval (form=137084910) at eval.c:2358 numargs = <value optimized out> args_left = 138383530 i = 3 argvals = {137084921, 137084949, 16, -1217216809, 141990492, -1217211703, -1217211472, -1217216809} fun = <value optimized out> val = <value optimized out> original_fun = 138508354 original_args = 137084918 funcar = <value optimized out> backtrace = {next = 0xbfffc12c, function = 0xbfffbebc, args = 0xbfffbe84, nargs = 3, evalargs = 1 '\001', debug_on_exit = 0 '\000'} #48 0x08199522 in internal_lisp_condition_case (var=138383530, bodyform=137084910, handlers=136475118) at eval.c:1407 val = <value optimized out> c = {tag = 138383530, val = 138383530, next = 0xbfffcb24, gcpro = 0x0, jmp = {{__jmpbuf = {136475112, 137084792, 44, -1073758248, 464420434, -671439043}, __mask_was_saved = 0, __saved_mask = {__val = {147000384, 146999632, 5, 137084309, 3221209076, 1, 0, 0, 139698176, 3221208952, 3221208984, 141939898, 2, 1073741824, 3221209048, 135886099, 0, 0, 173107064, 3221208956, 0, 160712224, 1, 138275976, 0, 0, 0, 137084304, 3221209076, 1, 141939896, 135889190}}}}, backlist = 0xbfffc12c, handlerlist = 0xbfffcbec, lisp_eval_depth = 13, pdlcount = 47, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0xbfffc054} ---Type <return> to continue, or q <return> to quit--- h = {handler = 136475118, var = 138383530, chosen_clause = 141350376, tag = 0xbfffbef4, next = 0xbfffcbec} #49 0x081cda4b in Fbyte_code (bytestr=137084777, vector=137084797, maxdepth=20) at bytecode.c:869 handlers = 136428128 body = <value optimized out> op = 5 stack = {pc = 0x83459fc "\210\016\026\205x", top = 0xbfffbff0, bottom = 0xbfffbff0, byte_string = 137084777, byte_string_start = 0x834598e "\b\021\n\020\v\022\306\034\307\v!\203|", constants = 137084797, next = 0xbfffcf14} top = 0xbfffbff0 result = <value optimized out> #50 0x081971f4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x5) at eval.c:3174 val = <value optimized out> syms_left = 138383530 next = <value optimized out> i = 1 optional = 0 rest = 0 #51 0x08197513 in Ffuncall (nargs=2, args=0xbfffc178) at eval.c:3047 fun = 1634758445 original_fun = 138408346 funcar = <value optimized out> numargs = 1 val = <value optimized out> backtrace = {next = 0xbfffce7c, function = 0xbfffc178, args = 0xbfffc17c, nargs = 1, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #52 0x08198855 in call1 (fn=138408346, arg1=264114085) at eval.c:2789 ret_ungc_val = 1634758445 args = {138408346, 264114085} #53 0x0812efb6 in timer_check_2 (do_it_now=1) at keyboard.c:4567 old_deactivate_mark = 138383530 vector = <value optimized out> idle_timers = 264114085 now = {tv_sec = 1285477260, tv_usec = 281947} #54 timer_check (do_it_now=1) at keyboard.c:4617 No locals. #55 0x0812f27b in readable_events (flags=1) at keyboard.c:3530 No locals. #56 0x0813337f in get_input_pending (flags=1, addr=<value optimized out>) at keyboard.c:6863 No locals. #57 0x081335a7 in detect_input_pending_run_timers (do_display=1) at keyboard.c:10511 old_timers_run = 2801 #58 0x081d4d84 in wait_reading_process_output (time_limit=30, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=138383530, wait_proc=0x0, just_wait_proc=0) at process.c:4784 old_timers_run = 2801 old_buffer = 0x9944620 old_window = 139886877 leave = 30 timeout_reduced_for_timers = 160712224 channel = <value optimized out> ---Type <return> to continue, or q <return> to quit--- nfds = 0 Available = {fds_bits = {4390944, 0 <repeats 31 times>}} Connecting = {fds_bits = {0 <repeats 32 times>}} check_connect = 0 check_delay = <value optimized out> no_avail = 0 xerrno = 11 proc = 30 timeout = {tv_sec = 0, tv_usec = 0} end_time = {tv_sec = 1285477290, tv_usec = 181772} wait_channel = -1 got_some_input = 0 #59 0x08059550 in sit_for (timeout=120, reading=1, do_display=1) at dispnew.c:6084 sec = 30 usec = 136428128 #60 0x08135309 in read_char (commandflag=1, nmaps=5, maps=0xbfffc8b0, prev_event=138383530, used_mouse_menu=0xbfffc9d8, end_time=0x0) at keyboard.c:2809 tem0 = <value optimized out> delay_level = <value optimized out> buffer_size = <value optimized out> c = 138383530 local_getcjmp = {{__jmpbuf = {0, 5, 147000288, -1073756072, 459267666, -1034684611}, __mask_was_saved = 0, __saved_mask = {__val = {160712229, 4294967295, 3221211036, 160712224, 3221211016, 136194736, 138383530, 138405738, 1, 4294967295, 3221211036, 4294967295, 3221211256, 135856839, 138383530, 138405738, 160712229, 135891365, 1, 3221211116, 138499714, 138510698, 160712224, 138408562, 3221211128, 135922645, 275254982, 275254998, 3221210856, 1, 3221211308, 1}}}} save_jump = {{__jmpbuf = {0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0 <repeats 32 times>}}}} key_already_recorded = 0 tem = <value optimized out> save = <value optimized out> previous_echo_area_message = 138383530 also_record = 138383530 reread = 0 polling_stopped_here = <value optimized out> orig_kboard = 0x8505398 #61 0x0813626c in read_key_sequence (keybuf=<value optimized out>, bufsize=<value optimized out>, prompt=<value optimized out>, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9349 interrupted_kboard = 0x8505398 key = <value optimized out> used_mouse_menu = 0 echo_local_start = 0 last_real_key_start = 20 keys_local_start = 0 from_string = <value optimized out> t = <value optimized out> echo_start = 0 keys_start = 0 nmaps = <value optimized out> nmaps_allocated = 5 defs = 0xbfffc880 submaps = <value optimized out> ---Type <return> to continue, or q <return> to quit--- orig_local_map = 154531238 orig_keymap = 138383530 localized_local_map = 0 first_binding = <value optimized out> first_unbound = <value optimized out> mock_input = <value optimized out> fkey = {parent = 142133830, map = 142133830, start = 0, end = 0} keytran = {parent = 138370790, map = 138370790, start = 0, end = 0} indec = {parent = 142133838, map = 142133838, start = 0, end = 0} shift_translated = 0 delayed_switch_frame = 138383530 original_uppercase = -1 original_uppercase_position = -1 starting_buffer = <value optimized out> fake_prefixed_keys = 138383530 #62 0x08138362 in command_loop_1 () at keyboard.c:1618 cmd = <value optimized out> keybuf = {468, 160715768, 182296288, 19, 1, 136483544, -1073755420, 4, 138742888, 160712229, 0, 2, 138742960, -1073755108, -1073755424, -1073755420, 4, 171835392, 138272780, -1073755404, 0, -1073755424, 136843336, 40, -1073755272, -1073755404, 136841352, 40, -1073755272, 136112361} i = <value optimized out> prev_modiff = 354 prev_buffer = 0x9944620 #63 0x08195da1 in internal_condition_case (bfun=0x8138190 <command_loop_1>, handlers=138414514, hfun=0x8130d30 <cmd_error>) at eval.c:1460 val = 1634758445 c = {tag = 138383530, val = 138383530, next = 0xbfffcc48, gcpro = 0x0, jmp = {{__jmpbuf = {146999632, 146999632, 147000272, -1073755128, 457547346, -697729731}, __mask_was_saved = 0, __saved_mask = {__val = {136604257, 137951407, 138383530, 3221212948, 138383530, 138533330, 138383530, 136841328, 138383530, 0, 3221212104, 135885321, 40, 138383530, 8, 19, 147000272, 146999632, 5, 136841333, 3221212320, 0, 3221212088, 50, 138383554, 19, 3221212216, 138970010, 2, 1073741824, 3221212232, 135886099}}}}, backlist = 0xbfffce7c, handlerlist = 0xbfffd24c, lisp_eval_depth = 12, pdlcount = 41, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0xbfffcf14} h = {handler = 138414514, var = 138383530, chosen_clause = -1073754932, tag = 0xbfffcb24, next = 0xbfffd24c} #64 0x081309d5 in command_loop_2 (ignore=138383530) at keyboard.c:1338 val = 1634758445 #65 0x08195e81 in internal_catch (tag=138499330, func=0x81309b0 <command_loop_2>, arg=138383530) at eval.c:1204 c = {tag = 138499330, val = 138383530, next = 0xbfffd184, gcpro = 0x0, jmp = {{__jmpbuf = {146999632, 146999632, 147000272, -1073754856, 457956946, -697367235}, __mask_was_saved = 0, __saved_mask = {__val = {51, 3221212392, 1, 3221212508, 1, 3221212344, 135891824, 3221212364, 138383530, 0, 138970010, 31, 0, 51, 138499714, 2, 138059824, 3221212472, 135886726, 1, 3221212508, 31, 138383530, 160712224, 160712224, 1, 138069264, 3221212588, 0, 3221212488, 138551282, 138551280}}}}, backlist = 0xbfffce7c, handlerlist = 0xbfffd24c, lisp_eval_depth = 12, pdlcount = 41, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0xbfffcf14} #66 0x08130b37 in command_loop () at keyboard.c:1303 val = 1634758445 #67 0x08130f0b in recursive_edit_1 () at keyboard.c:940 val = <value optimized out> #68 0x081554de in read_minibuf (map=<value optimized out>, initial=258970937, prompt=<value optimized out>, backup_n=<value optimized out>, expflag=0, histvar=138521178, histpos=0, defalt=138383530, allow_props=0, inherit_input_method=0) at minibuf.c:713 val = <value optimized out> mini_frame = <value optimized out> ambient_dir = 161391961 minibuffer = 160712229 input_method = 138383530 ---Type <return> to continue, or q <return> to quit--- enable_multibyte = <value optimized out> pos = 0 histstring = <value optimized out> empty_minibuf = -1 dummy = <value optimized out> #69 0x0815627b in Fread_string (prompt=157919137, initial_input=258970937, history=138383530, default_value=138383530, inherit_input_method=138383530) at minibuf.c:1056 val = <value optimized out> #70 0x081976a6 in Ffuncall (nargs=3, args=0xbfffcec0) at eval.c:3004 fun = <value optimized out> original_fun = <value optimized out> funcar = <value optimized out> numargs = 2 val = <value optimized out> backtrace = {next = 0xbfffcfec, function = 0xbfffcec0, args = 0xbfffcec4, nargs = 2, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = 0xbfffce20 i = 136428128 #71 0x081ce801 in Fbyte_code (bytestr=156155857, vector=154809221, maxdepth=12) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x95f97ed ")\207", top = 0xbfffcec8, bottom = 0xbfffcec0, byte_string = 156155857, byte_string_start = 0x95f9788 "\306\b!\203\f", constants = 154809221, next = 0xbfffd094} top = 0xbfffcec0 result = <value optimized out> #72 0x081971f4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x5) at eval.c:3174 val = <value optimized out> syms_left = 138383530 next = <value optimized out> i = 5 optional = 0 rest = 0 #73 0x08197513 in Ffuncall (nargs=6, args=0xbfffd030) at eval.c:3047 fun = 1634758445 original_fun = 157025554 funcar = <value optimized out> numargs = 5 val = <value optimized out> backtrace = {next = 0xbfffd134, function = 0xbfffd030, args = 0xbfffd034, nargs = 5, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #74 0x081ce801 in Fbyte_code (bytestr=156176881, vector=157609069, maxdepth=24) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x96010e3 "\210,\v?\205H", top = 0xbfffd044, bottom = 0xbfffd030, byte_string = 156176881, byte_string_start = 0x96010a4 "Ɖ\211\307\b\206\t", constants = 157609069, next = 0xbfffd2d4} top = 0xbfffd030 result = <value optimized out> #75 0x08196d88 in Feval (form=155603046) at eval.c:2358 numargs = <value optimized out> args_left = 138383530 i = 3 ---Type <return> to continue, or q <return> to quit--- argvals = {156176881, 157609069, 24, 138763776, 142449992, 0, 45, -1216045068} fun = <value optimized out> val = <value optimized out> original_fun = 138508354 original_args = 155603014 funcar = <value optimized out> backtrace = {next = 0xbfffd3ac, function = 0xbfffd14c, args = 0xbfffd114, nargs = 3, evalargs = 1 '\001', debug_on_exit = 0 '\000'} #76 0x08199522 in internal_lisp_condition_case (var=138850010, bodyform=155603046, handlers=155602222) at eval.c:1407 val = <value optimized out> c = {tag = 138383530, val = 138383530, next = 0xbfffe084, gcpro = 0x0, jmp = {{__jmpbuf = {155602216, 157609296, 17, -1073753496, 460414546, -671439043}, __mask_was_saved = 0, __saved_mask = {__val = {146999904, 146999632, 5, 157813733, 3221213828, 1, 0, 0, 263430512, 138383530, 1, 157062594, 2, 1073741824, 3221213800, 135886099, 1 <repeats 11 times>, 157813728, 3221213828, 1, 157062592, 1}}}}, backlist = 0xbfffd3ac, handlerlist = 0xbfffe14c, lisp_eval_depth = 9, pdlcount = 18, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0xbfffd2d4} h = {handler = 155602222, var = 138850010, chosen_clause = 1, tag = 0xbfffd184, next = 0xbfffe14c} #77 0x081cda4b in Fbyte_code (bytestr=156177217, vector=157609301, maxdepth=12) at bytecode.c:869 handlers = 136428128 body = <value optimized out> op = 5 stack = {pc = 0x960105a ")\207", top = 0xbfffd280, bottom = 0xbfffd280, byte_string = 156177217, byte_string_start = 0x960104c "\300\301!\210\302\303!\210Ď\305\306Ǐ)\207", constants = 157609301, next = 0xbfffd554} top = 0xbfffd280 result = <value optimized out> #78 0x081971f4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x5) at eval.c:3174 val = <value optimized out> syms_left = 138383530 next = <value optimized out> i = 7 optional = 1 rest = 0 #79 0x08197513 in Ffuncall (nargs=8, args=0xbfffd3f0) at eval.c:3047 fun = 1634758445 original_fun = 156778690 funcar = <value optimized out> numargs = 7 val = <value optimized out> backtrace = {next = 0xbfffd4bc, function = 0xbfffd3f0, args = 0xbfffd3f4, nargs = 7, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #80 0x08198c9c in Fapply (nargs=2, args=0xbfffd504) at eval.c:2506 i = <value optimized out> numargs = <value optimized out> spread_arg = 138383530 funcall_args = 0xbfffd3f0 fun = <value optimized out> retval = <value optimized out> sa_must_free = 0 #81 0x08197786 in Ffuncall (nargs=3, args=0xbfffd500) at eval.c:2971 fun = <value optimized out> ---Type <return> to continue, or q <return> to quit--- original_fun = 138500378 funcar = <value optimized out> numargs = 2 val = <value optimized out> backtrace = {next = 0xbfffd62c, function = 0xbfffd500, args = 0xbfffd504, nargs = 2, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #82 0x081ce801 in Fbyte_code (bytestr=156191065, vector=157018261, maxdepth=12) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x9600da2 "\207", top = 0xbfffd508, bottom = 0xbfffd500, byte_string = 156191065, byte_string_start = 0x9600d90 "\301\b@!\203\016", constants = 157018261, next = 0xbfffd7e4} top = 0xbfffd500 result = <value optimized out> #83 0x081971f4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x5) at eval.c:3174 val = <value optimized out> syms_left = 138383530 next = <value optimized out> i = 7 optional = 0 rest = 1 #84 0x08197513 in Ffuncall (nargs=8, args=0xbfffd670) at eval.c:3047 fun = 1634758445 original_fun = 154806058 funcar = <value optimized out> numargs = 7 val = <value optimized out> backtrace = {next = 0xbfffd73c, function = 0xbfffd670, args = 0xbfffd674, nargs = 7, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #85 0x08198c9c in Fapply (nargs=2, args=0xbfffd784) at eval.c:2506 i = <value optimized out> numargs = <value optimized out> spread_arg = 138383530 funcall_args = 0xbfffd670 fun = <value optimized out> retval = <value optimized out> sa_must_free = 0 #86 0x08197786 in Ffuncall (nargs=3, args=0xbfffd780) at eval.c:2971 fun = <value optimized out> original_fun = 138500378 funcar = <value optimized out> numargs = 2 val = <value optimized out> backtrace = {next = 0xbfffd8bc, function = 0xbfffd780, args = 0xbfffd784, nargs = 2, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #87 0x081ce801 in Fbyte_code (bytestr=156190697, vector=157018069, maxdepth=20) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x9600dc7 "\207", top = 0xbfffd788, bottom = 0xbfffd780, byte_string = 156190697, ---Type <return> to continue, or q <return> to quit--- byte_string_start = 0x9600dc0 "\301\302\303\304\b\"\"\207", constants = 157018069, next = 0xbfffd954} top = 0xbfffd780 result = <value optimized out> #88 0x081971f4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x5) at eval.c:3174 val = <value optimized out> syms_left = 138383530 next = <value optimized out> i = 0 optional = 4 rest = 136454488 #89 0x08197513 in Ffuncall (nargs=1, args=0xbfffd900) at eval.c:3047 fun = 1634758445 original_fun = 157018197 funcar = <value optimized out> numargs = 0 val = <value optimized out> backtrace = {next = 0xbfffda2c, function = 0xbfffd900, args = 0xbfffd904, nargs = 0, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #90 0x081ce801 in Fbyte_code (bytestr=156206737, vector=156298645, maxdepth=4) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x9600ab6 ")\207", top = 0xbfffd900, bottom = 0xbfffd900, byte_string = 156206737, byte_string_start = 0x9600ab0 "\b\021Î\n )\207", constants = 156298645, next = 0xbfffdac4} top = 0xbfffd900 result = <value optimized out> #91 0x081971f4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x5) at eval.c:3174 val = <value optimized out> syms_left = 138383530 next = <value optimized out> i = 2 optional = 0 rest = 0 #92 0x08197513 in Ffuncall (nargs=3, args=0xbfffda70) at eval.c:3047 fun = 1634758445 original_fun = 157063026 funcar = <value optimized out> numargs = 2 val = <value optimized out> backtrace = {next = 0xbfffdb9c, function = 0xbfffda70, args = 0xbfffda74, nargs = 2, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #93 0x081ce801 in Fbyte_code (bytestr=156191065, vector=157018261, maxdepth=12) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x9600d9d "\207\305\306\b\"\207", top = 0xbfffda78, bottom = 0xbfffda70, byte_string = 156191065, byte_string_start = 0x9600d90 "\301\b@!\203\016", constants = 157018261, next = 0xbfffdc54} top = 0xbfffda70 result = <value optimized out> #94 0x081971f4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x5) at eval.c:3174 val = <value optimized out> ---Type <return> to continue, or q <return> to quit--- syms_left = 138383530 next = <value optimized out> i = 8 optional = 0 rest = 1 #95 0x08197513 in Ffuncall (nargs=9, args=0xbfffdbe0) at eval.c:3047 fun = 1634758445 original_fun = 154806058 funcar = <value optimized out> numargs = 8 val = <value optimized out> backtrace = {next = 0xbfffdd2c, function = 0xbfffdbe0, args = 0xbfffdbe4, nargs = 8, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #96 0x081ce801 in Fbyte_code (bytestr=157919329, vector=156888837, maxdepth=36) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x969c5fb ")\207", top = 0xbfffdc00, bottom = 0xbfffdbe0, byte_string = 157919329, byte_string_start = 0x969c5e8 "\301\030\302\303\304\305\306\307 \310\311!\"\312\313\314\315&\b)\207", constants = 156888837, next = 0x0} top = 0xbfffdbe0 result = <value optimized out> #97 0x081971f4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x5) at eval.c:3174 val = <value optimized out> syms_left = 138383530 next = <value optimized out> i = 0 optional = 0 rest = 0 #98 0x08197513 in Ffuncall (nargs=1, args=0xbfffdd90) at eval.c:3047 fun = 1634758445 original_fun = 157320834 funcar = <value optimized out> numargs = 0 val = <value optimized out> backtrace = {next = 0xbfffdefc, function = 0xbfffdd90, args = 0xbfffdd94, nargs = 0, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #99 0x08198ee3 in apply1 (fn=157320834, arg=138383530) at eval.c:2756 ret_ungc_val = 1634758445 #100 0x08192f9b in Fcall_interactively (function=157320834, record_flag=138383530, keys=138411709) at callint.c:376 specs = 138383530 filter_specs = 138383530 teml = <value optimized out> up_event = 138383530 enable = 138383530 next_event = <value optimized out> prefix_arg = <value optimized out> string = <value optimized out> tem = <value optimized out> i = 2286 ---Type <return> to continue, or q <return> to quit--- j = <value optimized out> foo = 0 prompt1 = '\000' <repeats 85 times>, " ", '\000' <repeats 13 times> arg_from_tty = 0 key_count = <value optimized out> record_then_fail = <value optimized out> save_this_command = 157320834 save_last_command = 146070898 save_this_original_command = 157320834 save_real_this_command = 157320834 #101 0x081976e3 in Ffuncall (nargs=4, args=0xbfffdf40) at eval.c:2996 fun = <value optimized out> original_fun = <value optimized out> funcar = <value optimized out> numargs = 3 val = <value optimized out> backtrace = {next = 0x0, function = 0xbfffdf40, args = 0xbfffdf44, nargs = 3, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = 0xbfffdf44 i = 136428128 #102 0x08197991 in call3 (fn=138508546, arg1=157320834, arg2=138383530, arg3=138383530) at eval.c:2820 ret_ungc_val = 1634758445 args = {138508546, 157320834, 138383530, 138383530} #103 0x0813850a in command_loop_1 () at keyboard.c:1737 cmd = <value optimized out> keybuf = {96, 24, 432, 1024, 37, -1073749986, 138383530, 138383530, -1073749912, 135466509, 261260646, -1073749986, 37, -1073749876, -1208044170, 0, 0, 0, 0, 0, -1073749972, -1090461856, 0, 110886912, 138383530, 139514250, -1207974148, -1073749932, 0, 138653160} i = <value optimized out> prev_modiff = 281 prev_buffer = 0x9927608 #104 0x08195da1 in internal_condition_case (bfun=0x8138190 <command_loop_1>, handlers=138414514, hfun=0x8130d30 <cmd_error>) at eval.c:1460 val = 1634758445 c = {tag = 138383530, val = 138383530, next = 0xbfffe1a8, gcpro = 0x0, jmp = {{__jmpbuf = {138653160, 138653160, 138653176, -1073749656, 454254162, -697729731}, __mask_was_saved = 0, __saved_mask = {__val = {0, 1, 3087005920, 0, 0, 0, 3221217164, 3070816685, 0, 3071676404, 0, 3221217632, 3221217564, 3221217576, 3087005920, 0, 3067141600, 134548874, 3086946240, 134548148, 3073706600, 3087003588, 3070372296, 37, 3221217356, 3086923126, 3065318852, 3070389756, 3073706664, 3221217904, 110932256, 3087003588}}}}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0} h = {handler = 138414514, var = 138383530, chosen_clause = 138383554, tag = 0xbfffe084, next = 0x0} #105 0x081309d5 in command_loop_2 (ignore=138383530) at keyboard.c:1338 val = 1634758445 #106 0x08195e81 in internal_catch (tag=138412586, func=0x81309b0 <command_loop_2>, arg=138383530) at eval.c:1204 c = {tag = 138412586, val = 138383530, next = 0x0, gcpro = 0x0, jmp = {{__jmpbuf = {138653160, 138653160, 138653176, -1073749384, 454073938, -697367235}, __mask_was_saved = 0, __saved_mask = {__val = {3221217892, 3221218040, 135464770, 3221217904, 0 <repeats 12 times>, 3070807150, 0, 0, 0, 3070807150, 0, 0, 0, 138403280, 1, 138069264, 0, 14, 3221217996, 138551282, 138551280}}}}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0} #107 0x08130b81 in command_loop () at keyboard.c:1317 No locals. #108 0x08130f0b in recursive_edit_1 () at keyboard.c:940 val = <value optimized out> #109 0x08131032 in Frecursive_edit () at keyboard.c:1002 ---Type <return> to continue, or q <return> to quit--- buffer = 138383530 #110 0x081274a1 in main (argc=<value optimized out>, argv=<value optimized out>) at emacs.c:1704 dummy = -1073748472 stack_bottom_variable = 8 '\b' do_initial_setlocale = 138653160 skip_args = 0 rlim = {rlim_cur = 8388608, rlim_max = 18446744073709551615} no_loadup = 0 junk = 0x0 dname_arg = 0x0 ch_to_dir = 0xbfffe5d8 "\b\346\377\277\071\215\037\b\004\023\026\267\364\017\026\267\020\346\377\277\364\017\026\267" ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-25 11:39 ` Thierry Volpiatto 2010-09-25 11:59 ` Eli Zaretskii @ 2010-09-25 12:01 ` Juanma Barranquero 2010-09-25 12:45 ` Thierry Volpiatto 1 sibling, 1 reply; 48+ messages in thread From: Juanma Barranquero @ 2010-09-25 12:01 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: 7098 On Sat, Sep 25, 2010 at 13:39, Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote: > Ah! ok, i use -j3 in my make.conf according to gentoo recommendations > for my processor i686 Genuine Intel(R) CPU T2130 @ 1.86GHz GenuineIntel. This affects how many processes the make uses, not the flags passed to the compiler, doesn't it? > I can crash at everytime now using the same command that recurse > through a big tree and match regexp in file (like rgrep but all lisp). Could you try compiling Emacs with a 3.X release of GCC? Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-25 12:01 ` Juanma Barranquero @ 2010-09-25 12:45 ` Thierry Volpiatto 2010-09-25 20:45 ` Juanma Barranquero 0 siblings, 1 reply; 48+ messages in thread From: Thierry Volpiatto @ 2010-09-25 12:45 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 7098 Juanma Barranquero <lekktu@gmail.com> writes: > On Sat, Sep 25, 2010 at 13:39, Thierry Volpiatto > <thierry.volpiatto@gmail.com> wrote: > >> Ah! ok, i use -j3 in my make.conf according to gentoo recommendations >> for my processor i686 Genuine Intel(R) CPU T2130 @ 1.86GHz GenuineIntel. > > This affects how many processes the make uses, not the flags passed to > the compiler, doesn't it? I really don't know, i have to check the doc. Maybe i am wrong and what you use in command line is the same as CFLAGS="-O3 -march=i686 -pipe" ^^^ in make.conf and not MAKEOPTS="-j3" >> I can crash at everytime now using the same command that recurse >> through a big tree and match regexp in file (like rgrep but all lisp). > > Could you try compiling Emacs with a 3.X release of GCC? No, i remember it was not easy to switch from 3.* to 4.*. http://www.gentoo.org/doc/en/gcc-upgrading.xml -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-25 12:45 ` Thierry Volpiatto @ 2010-09-25 20:45 ` Juanma Barranquero 0 siblings, 0 replies; 48+ messages in thread From: Juanma Barranquero @ 2010-09-25 20:45 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: 7098 On Sat, Sep 25, 2010 at 14:45, Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote: > Maybe i am wrong and what you use in command line is the same as > CFLAGS="-O3 -march=i686 -pipe" Seems like it is optimized, then. > No, i remember it was not easy to switch from 3.* to 4.*. OK, I understand. Juanma ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-24 17:53 bug#7098: Emacs24 crash with segmentation fault Thierry Volpiatto 2010-09-24 18:18 ` Eli Zaretskii @ 2010-12-06 20:39 ` Chong Yidong 2010-12-06 21:15 ` Thierry Volpiatto 2010-12-09 7:25 ` Thierry Volpiatto 2010-12-18 9:16 ` Thierry Volpiatto 2 siblings, 2 replies; 48+ messages in thread From: Chong Yidong @ 2010-12-06 20:39 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: 7098 > emacs24 become unusable as it crash several times a day always with > same error. > >> Is it possible for you to find the last version which did not >> crash (or the first one that did)? "bzr bisect" makes this easier, >> but you could do this by hand as well, using "bzr revert -r". > > It will be difficult because i don't build emacs myself actually, i > use the gentoo package of Emacs-vcs. > > However, i will build an emacs from git tomorrow and try to downgrade > until i find a working version. Were you able to track down the problem? Is it still present? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-12-06 20:39 ` Chong Yidong @ 2010-12-06 21:15 ` Thierry Volpiatto 2010-12-09 7:25 ` Thierry Volpiatto 1 sibling, 0 replies; 48+ messages in thread From: Thierry Volpiatto @ 2010-12-06 21:15 UTC (permalink / raw) To: bug-gnu-emacs Chong Yidong <cyd@stupidchicken.com> writes: >> emacs24 become unusable as it crash several times a day always with >> same error. >> >>> Is it possible for you to find the last version which did not >>> crash (or the first one that did)? "bzr bisect" makes this easier, >>> but you could do this by hand as well, using "bzr revert -r". >> >> It will be difficult because i don't build emacs myself actually, i >> use the gentoo package of Emacs-vcs. >> >> However, i will build an emacs from git tomorrow and try to downgrade >> until i find a working version. > > Were you able to track down the problem? No, didn't have the time to try again. > Is it still present? Don't know, i use mostly emacs-23 branch actually. I will try in next days to use again an Emacs24 in gdb and will tell you. -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-12-06 20:39 ` Chong Yidong 2010-12-06 21:15 ` Thierry Volpiatto @ 2010-12-09 7:25 ` Thierry Volpiatto 2010-12-15 1:50 ` Chong Yidong 1 sibling, 1 reply; 48+ messages in thread From: Thierry Volpiatto @ 2010-12-09 7:25 UTC (permalink / raw) To: Chong Yidong; +Cc: 7098 Chong Yidong <cyd@stupidchicken.com> writes: >> emacs24 become unusable as it crash several times a day always with >> same error. >> >>> Is it possible for you to find the last version which did not >>> crash (or the first one that did)? "bzr bisect" makes this easier, >>> but you could do this by hand as well, using "bzr revert -r". >> >> It will be difficult because i don't build emacs myself actually, i >> use the gentoo package of Emacs-vcs. >> >> However, i will build an emacs from git tomorrow and try to downgrade >> until i find a working version. > > Were you able to track down the problem? Is it still present? It is much better, i work in emacs24 yesterday without crash, but today just copying/yanking in scratch: Program received signal SIGSEGV, Segmentation fault. mark_object (arg=655366) at alloc.c:5556 5556 if (CONS_MARKED_P (ptr)) #0 mark_object (arg=655366) at alloc.c:5556 #1 0x081904fd in mark_object (arg=186620870) at alloc.c:5567 #2 0x08190535 in mark_object (arg=186644482) at alloc.c:5460 #3 0x08190e04 in mark_maybe_pointer () at alloc.c:4127 #4 mark_memory () at alloc.c:4177 #5 mark_stack () at alloc.c:4410 #6 0x081915da in Fgarbage_collect () at alloc.c:4992 #7 0x081deaf3 in Fbyte_code (bytestr=137115481, vector=137115501, maxdepth=36) at bytecode.c:714 #8 0x081a6e44 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0xa0000) at eval.c:3174 #9 0x081a7163 in Ffuncall (nargs=4, args=0xbfff7fe0) at eval.c:3047 #10 0x081de8b1 in Fbyte_code (bytestr=137112857, vector=137112877, maxdepth=20) at bytecode.c:679 #11 0x081a6e44 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0xa0000) at eval.c:3174 #12 0x081a7163 in Ffuncall (nargs=4, args=0xbfff8160) at eval.c:3047 #13 0x081de8b1 in Fbyte_code (bytestr=137111793, vector=137111813, maxdepth=16) at bytecode.c:679 #14 0x081a6e44 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0xa0000) at eval.c:3174 #15 0x081a7163 in Ffuncall (nargs=3, args=0xbfff8394) at eval.c:3047 #16 0x081a8619 in run_hook_with_args (nargs=<value optimized out>, args=0xbfff8394, cond=to_completion) at eval.c:2679 #17 0x081a73d6 in Ffuncall (nargs=4, args=0xbfff8390) at eval.c:2971 #18 0x081de8b1 in Fbyte_code (bytestr=136675017, vector=137124173, maxdepth=16) at bytecode.c:679 #19 0x081a69d8 in Feval (form=137124150) at eval.c:2358 #20 0x081a9172 in internal_lisp_condition_case (var=138732314, bodyform=137124150, handlers=137124198) at eval.c:1407 #21 0x081ddafb in Fbyte_code (bytestr=137123929, vector=137123949, maxdepth=32) at bytecode.c:869 #22 0x081a6e44 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0xa0000) at eval.c:3174 #23 0x081a7163 in Ffuncall (nargs=3, args=0xbfff8750) at eval.c:3047 #24 0x081de8b1 in Fbyte_code (bytestr=137123657, vector=137123677, maxdepth=40) at bytecode.c:679 #25 0x081a6e44 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0xa0000) at eval.c:3174 #26 0x081a7163 in Ffuncall (nargs=2, args=0xbfff8a28) at eval.c:3047 #27 0x081a56fe in internal_condition_case_n (bfun=0x81a6fa0 <Ffuncall>, nargs=2, args=0xbfff8a28, handlers=138465506, hfun=0x807e030 <safe_eval_handler>) at eval.c:1603 #28 0x08079592 in safe_call (nargs=2, args=0xbfff8a28) at xdisp.c:2438 #29 0x08079605 in safe_call1 (fn=140643738, arg=12972) at xdisp.c:2457 #30 0x080796f4 in handle_fontified_prop (it=0xbfff9ddc) at xdisp.c:3440 #31 0x08073c5f in handle_stop (it=0xbfff9ddc) at xdisp.c:3159 #32 0x080790c6 in next_element_from_buffer (it=0xbfff9ddc) at xdisp.c:6884 #33 0x08076162 in get_next_display_element (it=0xbfff9ddc) at xdisp.c:5855 #34 0x08082431 in display_line (it=0xbfff9ddc) at xdisp.c:17528 #35 0x08097553 in try_window_id (w=0xa3f8d10) at xdisp.c:15913 #36 0x08099497 in redisplay_window (window=<value optimized out>, just_this_one_p=<value optimized out>) at xdisp.c:14249 #37 0x0809bb76 in redisplay_window_1 (window=171937045) at xdisp.c:12566 #38 0x081a58f7 in internal_condition_case_1 (bfun=0x809bb50 <redisplay_window_1>, arg=171937045, handlers=138447630, hfun=0x806bd30 <redisplay_window_error>) at eval.c:1505 #39 0x08087086 in redisplay_internal (preserve_echo_area=<value optimized out>) at xdisp.c:12192 #40 0x08143760 in read_char (commandflag=1, nmaps=5, maps=0xbfffddc0, prev_event=138465482, used_mouse_menu=0xbfffdee8, end_time=0x0) at keyboard.c:2554 #41 0x08145a1c in read_key_sequence (keybuf=<value optimized out>, bufsize=<value optimized out>, prompt=<value optimized out>, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9331 #42 0x08147b43 in command_loop_1 () at keyboard.c:1601 #43 0x081a59f1 in internal_condition_case (bfun=0x8147970 <command_loop_1>, handlers=138496490, hfun=0x8140510 <cmd_error>) at eval.c:1460 #44 0x081401b5 in command_loop_2 (ignore=138465482) at keyboard.c:1321 #45 0x081a5ad1 in internal_catch (tag=138492938, func=0x8140190 <command_loop_2>, arg=138465482) at eval.c:1204 ---Type <return> to continue, or q <return> to quit--- #46 0x08140361 in command_loop () at keyboard.c:1300 #47 0x081406eb in recursive_edit_1 () at keyboard.c:923 #48 0x08140812 in Frecursive_edit () at keyboard.c:985 #49 0x08136906 in main (argc=<value optimized out>, argv=<value optimized out>) at emacs.c:1716 -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-12-09 7:25 ` Thierry Volpiatto @ 2010-12-15 1:50 ` Chong Yidong 2010-12-15 6:46 ` Thierry Volpiatto 0 siblings, 1 reply; 48+ messages in thread From: Chong Yidong @ 2010-12-15 1:50 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: 7098 Thierry Volpiatto <thierry.volpiatto@gmail.com> writes: >> Were you able to track down the problem? Is it still present? > It is much better, i work in emacs24 yesterday without crash, but today > just copying/yanking in scratch: In a earlier message, you said that you were going to bisect to try to find the problem. Could you do that? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-12-15 1:50 ` Chong Yidong @ 2010-12-15 6:46 ` Thierry Volpiatto 2010-12-16 1:15 ` Chong Yidong 0 siblings, 1 reply; 48+ messages in thread From: Thierry Volpiatto @ 2010-12-15 6:46 UTC (permalink / raw) To: Chong Yidong; +Cc: 7098 Chong Yidong <cyd@stupidchicken.com> writes: > Thierry Volpiatto <thierry.volpiatto@gmail.com> writes: > >>> Were you able to track down the problem? Is it still present? > >> It is much better, i work in emacs24 yesterday without crash, but today >> just copying/yanking in scratch: > > In a earlier message, you said that you were going to bisect to try to > find the problem. Could you do that? No fail to do that. I had yesterday 2 crashs in ten minutes doing nothing special. I have switched again on 23.2.91. -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-12-15 6:46 ` Thierry Volpiatto @ 2010-12-16 1:15 ` Chong Yidong 2010-12-16 8:03 ` Thierry Volpiatto 0 siblings, 1 reply; 48+ messages in thread From: Chong Yidong @ 2010-12-16 1:15 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: 7098 Thierry Volpiatto <thierry.volpiatto@gmail.com> writes: >> In a earlier message, you said that you were going to bisect to try to >> find the problem. Could you do that? > No fail to do that. > I had yesterday 2 crashs in ten minutes doing nothing special. > I have switched again on 23.2.91. Since you are the only person who has been experiencing this crash, please make an effort to bisect and find the bug. Otherwise, the chances of it being fixed are low. From your previous message, the bug started at least on Sep 21, so I would revert to a copy from July and see if the bug happens. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-12-16 1:15 ` Chong Yidong @ 2010-12-16 8:03 ` Thierry Volpiatto 2010-12-16 17:35 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Thierry Volpiatto @ 2010-12-16 8:03 UTC (permalink / raw) To: Chong Yidong; +Cc: 7098 Chong Yidong <cyd@stupidchicken.com> writes: > Thierry Volpiatto <thierry.volpiatto@gmail.com> writes: > >>> In a earlier message, you said that you were going to bisect to try to >>> find the problem. Could you do that? >> No fail to do that. >> I had yesterday 2 crashs in ten minutes doing nothing special. >> I have switched again on 23.2.91. > > Since you are the only person who has been experiencing this crash, > please make an effort to bisect and find the bug. Otherwise, the > chances of it being fixed are low. > > From your previous message, the bug started at least on Sep 21, so I > would revert to a copy from July and see if the bug happens. I have tried to bissect like this without success. The main reason is i think the bug is not directly related to Emacs but to the version of gcc (4.4.4) you use to compile emacs and/or maybe the gtk+ version (2.22.1) that is used on this system (just a guess). See related post of Juanma about gcc. As i said in precedents post, it's out of question i switch back to an other version of gcc (3-*). -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-12-16 8:03 ` Thierry Volpiatto @ 2010-12-16 17:35 ` Eli Zaretskii 2010-12-16 18:07 ` Thierry Volpiatto 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2010-12-16 17:35 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: cyd, 7098 > From: Thierry Volpiatto <thierry.volpiatto@gmail.com> > Date: Thu, 16 Dec 2010 09:03:54 +0100 > Cc: 7098@debbugs.gnu.org > > The main reason is i think the bug is not directly related to Emacs but > to the version of gcc (4.4.4) you use to compile emacs and/or maybe the gtk+ > version (2.22.1) that is used on this system (just a guess). > See related post of Juanma about gcc. > As i said in precedents post, it's out of question i switch back to an > other version of gcc (3-*). What about switching to a newer GCC (4.5.x)? Is that possible for you? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-12-16 17:35 ` Eli Zaretskii @ 2010-12-16 18:07 ` Thierry Volpiatto 2010-12-16 18:10 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Thierry Volpiatto @ 2010-12-16 18:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, 7098 Eli Zaretskii <eliz@gnu.org> writes: >> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >> Date: Thu, 16 Dec 2010 09:03:54 +0100 >> Cc: 7098@debbugs.gnu.org >> >> The main reason is i think the bug is not directly related to Emacs but >> to the version of gcc (4.4.4) you use to compile emacs and/or maybe the gtk+ >> version (2.22.1) that is used on this system (just a guess). >> See related post of Juanma about gcc. >> As i said in precedents post, it's out of question i switch back to an >> other version of gcc (3-*). > > What about switching to a newer GCC (4.5.x)? Is that possible for > you? No, sorry. It could be possible, but my system will be maybe unstable if i do that. The 4.5.1-r1 version of gcc is still unstable and i don't want to switch to it yet.Thus it is a major version switch (4.4==>4.5) and it's always tricky to change, even more to switch back to the stable version (a lot of packages to recompile, etc..). -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-12-16 18:07 ` Thierry Volpiatto @ 2010-12-16 18:10 ` Eli Zaretskii 2010-12-16 18:43 ` Thierry Volpiatto 0 siblings, 1 reply; 48+ messages in thread From: Eli Zaretskii @ 2010-12-16 18:10 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: cyd, 7098 > From: Thierry Volpiatto <thierry.volpiatto@gmail.com> > Cc: cyd@stupidchicken.com, 7098@debbugs.gnu.org > Date: Thu, 16 Dec 2010 19:07:13 +0100 > > > What about switching to a newer GCC (4.5.x)? Is that possible for > > you? > No, sorry. Do the crashes go away if you compile without optimizations? ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-12-16 18:10 ` Eli Zaretskii @ 2010-12-16 18:43 ` Thierry Volpiatto 2010-12-16 19:25 ` Eli Zaretskii 0 siblings, 1 reply; 48+ messages in thread From: Thierry Volpiatto @ 2010-12-16 18:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, 7098 Eli Zaretskii <eliz@gnu.org> writes: >> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >> Cc: cyd@stupidchicken.com, 7098@debbugs.gnu.org >> Date: Thu, 16 Dec 2010 19:07:13 +0100 >> >> > What about switching to a newer GCC (4.5.x)? Is that possible for >> > you? >> No, sorry. > > Do the crashes go away if you compile without optimizations? Don't know, never tried. What do i have to disable (or change) in my make.conf? Actually i have: CFLAGS="-O3 -march=i686 -pipe" CXXFLAGS="${CFLAGS}" MAKEOPTS="-j3" -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-12-16 18:43 ` Thierry Volpiatto @ 2010-12-16 19:25 ` Eli Zaretskii 2010-12-16 19:36 ` Thierry Volpiatto 2010-12-18 7:24 ` Thierry Volpiatto 0 siblings, 2 replies; 48+ messages in thread From: Eli Zaretskii @ 2010-12-16 19:25 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: cyd, 7098 > From: Thierry Volpiatto <thierry.volpiatto@gmail.com> > Cc: cyd@stupidchicken.com, 7098@debbugs.gnu.org > Date: Thu, 16 Dec 2010 19:43:09 +0100 > > > Do the crashes go away if you compile without optimizations? > Don't know, never tried. > What do i have to disable (or change) in my make.conf? > > Actually i have: > > CFLAGS="-O3 -march=i686 -pipe" Try CFLAGS="-O0 -pipe" ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-12-16 19:25 ` Eli Zaretskii @ 2010-12-16 19:36 ` Thierry Volpiatto 2010-12-18 7:24 ` Thierry Volpiatto 1 sibling, 0 replies; 48+ messages in thread From: Thierry Volpiatto @ 2010-12-16 19:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, 7098 Eli Zaretskii <eliz@gnu.org> writes: >> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >> Cc: cyd@stupidchicken.com, 7098@debbugs.gnu.org >> Date: Thu, 16 Dec 2010 19:43:09 +0100 >> >> > Do the crashes go away if you compile without optimizations? >> Don't know, never tried. >> What do i have to disable (or change) in my make.conf? >> >> Actually i have: >> >> CFLAGS="-O3 -march=i686 -pipe" > > Try > > CFLAGS="-O0 -pipe" Ok, thanks Eli, i will try to build an emacs with these settings as soon as possible. -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-12-16 19:25 ` Eli Zaretskii 2010-12-16 19:36 ` Thierry Volpiatto @ 2010-12-18 7:24 ` Thierry Volpiatto 1 sibling, 0 replies; 48+ messages in thread From: Thierry Volpiatto @ 2010-12-18 7:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, 7098 Hi Eli, Eli Zaretskii <eliz@gnu.org> writes: >> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >> Cc: cyd@stupidchicken.com, 7098@debbugs.gnu.org >> Date: Thu, 16 Dec 2010 19:43:09 +0100 >> >> > Do the crashes go away if you compile without optimizations? >> Don't know, never tried. >> What do i have to disable (or change) in my make.conf? >> >> Actually i have: >> >> CFLAGS="-O3 -march=i686 -pipe" > > Try > > CFLAGS="-O0 -pipe" I have compiled emacs24 with this value of CFLAGS and it seem to work fine. I have then recompiled with -g option added (CFLAGS="-O0 -g -pipe") and i had no crashes. I continue running Emacs in gdb and will tell you if something occur. -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-09-24 17:53 bug#7098: Emacs24 crash with segmentation fault Thierry Volpiatto 2010-09-24 18:18 ` Eli Zaretskii 2010-12-06 20:39 ` Chong Yidong @ 2010-12-18 9:16 ` Thierry Volpiatto 2010-12-18 10:08 ` Eli Zaretskii 2 siblings, 1 reply; 48+ messages in thread From: Thierry Volpiatto @ 2010-12-18 9:16 UTC (permalink / raw) To: bug-gnu-emacs Thierry Volpiatto <thierry.volpiatto@gmail.com> writes: > Hi Eli, > > Eli Zaretskii <eliz@gnu.org> writes: > >>> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >>> Cc: cyd@stupidchicken.com, 7098@debbugs.gnu.org >>> Date: Thu, 16 Dec 2010 19:43:09 +0100 >>> >>> > Do the crashes go away if you compile without optimizations? >>> Don't know, never tried. >>> What do i have to disable (or change) in my make.conf? >>> >>> Actually i have: >>> >>> CFLAGS="-O3 -march=i686 -pipe" >> >> Try >> >> CFLAGS="-O0 -pipe" > > I have compiled emacs24 with this value of CFLAGS and it seem to work > fine. > I have then recompiled with -g option added (CFLAGS="-O0 -g -pipe") and i had no crashes. > I continue running Emacs in gdb and will tell you if something occur. First crash since yesterday when closing w3m: Program received signal SIGSEGV, Segmentation fault. 0x081903b7 in mark_object (arg=172893790) at alloc.c:5577 5577 FLOAT_MARK (XFLOAT (obj)); (gdb) bt full #0 0x081903b7 in mark_object (arg=172893790) at alloc.c:5577 obj = <value optimized out> #1 0x081905a5 in mark_object (arg=172490834) at alloc.c:5460 ptr = 0xa480050 obj = <value optimized out> #2 0x08190e74 in mark_maybe_pointer () at alloc.c:4127 obj = 13 m = <value optimized out> #3 mark_memory () at alloc.c:4177 p = <value optimized out> pp = 0xbfffdd30 #4 mark_stack () at alloc.c:4410 j = {o = 0, j = {{__jmpbuf = {0, 1074266114, 0, -1073752632, -1696438098, 1465006529}, __mask_was_saved = 0, __saved_mask = {__val = {0, 138120960, 138722072, 3221214616, 135857517, 138491786, 77, 249, 167087104, 140743645, 3221214600, 248, 138456792, 138120960, 172343424, 728, 2624551902, 138469578, 69, 3221226518, 138456064, 138921598, 0, 3221214632, 0, 138501272, 0, 3221214664, 135494133, 138469578, 159486224, 3221356668}}}}} stack_grows_down_p = 0 end = 0xbfffe588 #5 0x0819164a in Fgarbage_collect () at alloc.c:4992 bind = <value optimized out> catch = <value optimized out> handler = <value optimized out> stack_top_variable = 8 '\b' i = <value optimized out> message_p = 0 total = {138129968, -1073752380, 1, 138604712, 138818168, 138469602, 138818168, -1073752328} t1 = {tv_sec = 1292663088, tv_usec = 883100} t2 = {tv_sec = -1073752068, tv_usec = -1073752384} #6 0x081dea63 in Fbyte_code (bytestr=148241241, vector=149386573, maxdepth=20) at bytecode.c:714 op = 13 stack = {pc = 0x8e2b679 "A", top = 0xbfffd6bc, bottom = 0xbfffd6c0, byte_string = 148241241, byte_string_start = 0x8e2b644 "\b;\203W", constants = 149386573, next = 0xbfffd8a4} top = 0xbfffd6bc result = <value optimized out> #7 0x081a6eb4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0xd) at eval.c:3174 val = <value optimized out> syms_left = 138469578 next = <value optimized out> i = 1 optional = 1 rest = 0 #8 0x081a71d3 in Ffuncall (nargs=2, args=0xbfffd840) at eval.c:3047 fun = 0 original_fun = 148731514 funcar = <value optimized out> numargs = 1 val = <value optimized out> backtrace = {next = 0xbfffd97c, function = 0xbfffd840, args = 0xbfffd844, nargs = 1, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> ---Type <return> to continue, or q <return> to quit--- i = <value optimized out> #9 0x081de821 in Fbyte_code (bytestr=149867225, vector=149173205, maxdepth=24) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x8eafd41 "\210\323c\210\202k", top = 0xbfffd844, bottom = 0xbfffd840, byte_string = 149867225, byte_string_start = 0x8eafcc4 "\b\205", <incomplete sequence \304>, constants = 149173205, next = 0xbfffda34} top = 0xbfffd840 result = <value optimized out> #10 0x081a6eb4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0xd) at eval.c:3174 val = <value optimized out> syms_left = 138469578 next = <value optimized out> i = 4 optional = 1 rest = 0 #11 0x081a71d3 in Ffuncall (nargs=5, args=0xbfffd9c0) at eval.c:3047 fun = 0 original_fun = 149240410 funcar = <value optimized out> numargs = 4 val = <value optimized out> backtrace = {next = 0xbfffdb0c, function = 0xbfffd9c0, args = 0xbfffd9c4, nargs = 4, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #12 0x081de821 in Fbyte_code (bytestr=148572073, vector=148573725, maxdepth=36) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x8eaf072 "\210)\307\020\331\332!\207", top = 0xbfffd9d0, bottom = 0xbfffd9c0, byte_string = 148572073, byte_string_start = 0x8eaf010 "\b\205i", constants = 148573725, next = 0xbfffdba4} top = 0xbfffd9c0 result = <value optimized out> #13 0x081a6eb4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0xd) at eval.c:3174 val = <value optimized out> syms_left = 138469578 next = <value optimized out> i = 0 optional = 0 rest = 0 #14 0x081a71d3 in Ffuncall (nargs=1, args=0xbfffdb50) at eval.c:3047 fun = 0 original_fun = 148566434 funcar = <value optimized out> numargs = 0 val = <value optimized out> backtrace = {next = 0xbfffdc7c, function = 0xbfffdb50, args = 0xbfffdb54, nargs = 0, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #15 0x081de821 in Fbyte_code (bytestr=148535169, vector=149018877, maxdepth=16) at bytecode.c:679 op = <value optimized out> stack = {pc = 0x8daeea7 "\210\330 \210\016\036\203w", top = 0xbfffdb50, bottom = 0xbfffdb50, byte_string = 148535169, byte_string_start = 0x8daee3c "\306\307!\310\030\306\307!)\031\211\032G\tGU\204\035", constants = 149018877, next = 0x0} ---Type <return> to continue, or q <return> to quit--- top = 0xbfffdb50 result = <value optimized out> #16 0x081a6eb4 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0xd) at eval.c:3174 val = <value optimized out> syms_left = 138469578 next = <value optimized out> i = 1 optional = 1 rest = 0 #17 0x081a71d3 in Ffuncall (nargs=2, args=0xbfffdd10) at eval.c:3047 fun = 0 original_fun = 147285242 funcar = <value optimized out> numargs = 1 val = <value optimized out> backtrace = {next = 0xbfffdeac, function = 0xbfffdd10, args = 0xbfffdd14, nargs = 1, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = <value optimized out> i = <value optimized out> #18 0x081a3f97 in Fcall_interactively (function=147285242, record_flag=138469578, keys=138498805) at callint.c:849 val = <value optimized out> specs = 138469578 filter_specs = <value optimized out> teml = <value optimized out> up_event = 138469578 enable = 0 next_event = <value optimized out> prefix_arg = <value optimized out> string = <value optimized out> tem = <value optimized out> i = 2 j = <value optimized out> foo = 0 prompt1 = '\000' <repeats 99 times> arg_from_tty = 0 key_count = <value optimized out> record_then_fail = <value optimized out> save_this_command = 147285242 save_last_command = 148953410 save_this_original_command = 147285242 save_real_this_command = 147285242 #19 0x081a73a3 in Ffuncall (nargs=4, args=0xbfffdef0) at eval.c:2996 fun = <value optimized out> original_fun = <value optimized out> funcar = <value optimized out> numargs = 3 val = <value optimized out> backtrace = {next = 0x0, function = 0xbfffdef0, args = 0xbfffdef4, nargs = 3, evalargs = 0 '\000', debug_on_exit = 0 '\000'} internal_args = 0xbfffdef4 i = 8192 ---Type <return> to continue, or q <return> to quit--- #20 0x081a7651 in call3 (fn=138595418, arg1=147285242, arg2=138469578, arg3=138469578) at eval.c:2820 ret_ungc_val = 0 args = {138595418, 147285242, 138469578, 138469578} #21 0x08147d2a in command_loop_1 () at keyboard.c:1720 cmd = <value optimized out> keybuf = {324, 388, 460, 40, -1233865128, -1073750066, 138469578, 138469578, -1073749992, 135530045, 164367918, -1073750066, -1073749960, -1208044282, 0, 0, 0, 0, 0, 0, -1073750052, -1090461936, 0, 134545408, 138469578, 138793242, -1073750016, 0, 23, 138867080} i = <value optimized out> prev_modiff = 2058 prev_buffer = 0xa0cc560 #22 0x081a5a61 in internal_condition_case (bfun=0x81479b0 <command_loop_1>, handlers=138500586, hfun=0x8140560 <cmd_error>) at eval.c:1460 val = 0 c = {tag = 138469578, val = 138469578, next = 0xbfffe158, gcpro = 0x0, jmp = {{__jmpbuf = {138867080, 138867080, 138867096, -1073749736, -1702115154, 1375718337}, __mask_was_saved = 0, __saved_mask = {__val = {1, 3087005920, 0, 0, 0, 0, 3221217084, 3065770045, 0, 0, 3221217552, 3221217484, 3221217496, 3059482612, 3087005920, 0, 3059417090, 3086946160, 134550982, 3067322984, 3087003588, 3065326024, 40, 3221217272, 3086923014, 3221217296, 3059465684, 3065343484, 3067323048, 3221217824, 110932256, 3087003588}}}}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0} h = {handler = 138500586, var = 138469578, chosen_clause = 138469602, tag = 0xbfffe034, next = 0x0} #23 0x08140205 in command_loop_2 (ignore=138469578) at keyboard.c:1321 val = 0 #24 0x081a5b41 in internal_catch (tag=138497034, func=0x81401e0 <command_loop_2>, arg=138469578) at eval.c:1204 c = {tag = 138497034, val = 138469578, next = 0x0, gcpro = 0x0, jmp = {{__jmpbuf = {138867080, 138867080, 138867096, -1073749464, -1702295378, 1375581121}, __mask_was_saved = 0, __saved_mask = {__val = {3221217812, 3221217960, 135528306, 3221217824, 0 <repeats 12 times>, 3065760510, 0, 0, 0, 3065760510, 0, 0, 0, 138489328, 1, 138142272, 0, 14, 3221217916, 138638154, 138638152}}}}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0} #25 0x081403b1 in command_loop () at keyboard.c:1300 No locals. #26 0x0814073b in recursive_edit_1 () at keyboard.c:923 val = <value optimized out> #27 0x08140862 in Frecursive_edit () at keyboard.c:985 buffer = 138469578 #28 0x08136956 in main (argc=<value optimized out>, argv=<value optimized out>) at emacs.c:1716 dummy = -1073748552 stack_bottom_variable = 8 '\b' do_initial_setlocale = 138867080 skip_args = 0 rlim = {rlim_cur = 8388608, rlim_max = 18446744073709551615} no_loadup = 0 junk = 0x0 dname_arg = 0x0 ch_to_dir = 0xbfffe588 "\270\345\377\277\351\236 \b\004\003ɶ\364\377ȶ\300\345\377\277\364\377ȶ" -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-12-18 9:16 ` Thierry Volpiatto @ 2010-12-18 10:08 ` Eli Zaretskii 2010-12-21 11:34 ` Thierry Volpiatto 2010-12-28 13:14 ` Thierry Volpiatto 0 siblings, 2 replies; 48+ messages in thread From: Eli Zaretskii @ 2010-12-18 10:08 UTC (permalink / raw) To: Thierry Volpiatto; +Cc: bug-gnu-emacs > From: Thierry Volpiatto <thierry.volpiatto@gmail.com> > Date: Sat, 18 Dec 2010 10:16:10 +0100 > Cc: > > First crash since yesterday when closing w3m: > > Program received signal SIGSEGV, Segmentation fault. > 0x081903b7 in mark_object (arg=172893790) at alloc.c:5577 > 5577 FLOAT_MARK (XFLOAT (obj)); Ouch! > (gdb) bt full > #0 0x081903b7 in mark_object (arg=172893790) at alloc.c:5577 > obj = <value optimized out> How come values are "optimized out" when you compiled without optimizations? Can you show a sample GCC compilation command line from the build process, with all its switches? Also, please type "source /path/to/src/.gdbinit" at GDB's prompt (where "/path/to/src/" is the Emacs src directory), and then type "xbacktrace", to show the Lisp-level backtrace. Thanks. ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-12-18 10:08 ` Eli Zaretskii @ 2010-12-21 11:34 ` Thierry Volpiatto 2010-12-28 13:14 ` Thierry Volpiatto 1 sibling, 0 replies; 48+ messages in thread From: Thierry Volpiatto @ 2010-12-21 11:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: bug-gnu-emacs Eli Zaretskii <eliz@gnu.org> writes: >> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >> Date: Sat, 18 Dec 2010 10:16:10 +0100 >> Cc: >> >> First crash since yesterday when closing w3m: >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x081903b7 in mark_object (arg=172893790) at alloc.c:5577 >> 5577 FLOAT_MARK (XFLOAT (obj)); > > Ouch! yes! >> (gdb) bt full >> #0 0x081903b7 in mark_object (arg=172893790) at alloc.c:5577 >> obj = <value optimized out> > > How come values are "optimized out" when you compiled without > optimizations? Can you show a sample GCC compilation command line > from the build process, with all its switches? > > Also, please type "source /path/to/src/.gdbinit" at GDB's prompt > (where "/path/to/src/" is the Emacs src directory), and then type > "xbacktrace", to show the Lisp-level backtrace. Sorry, i have not the time actually to try to debug that, i have switched back to 23.2.91 that is stable, no crash. Maybe you could try to see why 23.2.* is stable and 24 is not. And what is wrong in alloc.c? -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
* bug#7098: Emacs24 crash with segmentation fault 2010-12-18 10:08 ` Eli Zaretskii 2010-12-21 11:34 ` Thierry Volpiatto @ 2010-12-28 13:14 ` Thierry Volpiatto 1 sibling, 0 replies; 48+ messages in thread From: Thierry Volpiatto @ 2010-12-28 13:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: bug-gnu-emacs Hi Eli, Eli Zaretskii <eliz@gnu.org> writes: >> From: Thierry Volpiatto <thierry.volpiatto@gmail.com> >> Date: Sat, 18 Dec 2010 10:16:10 +0100 >> Cc: >> >> First crash since yesterday when closing w3m: >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x081903b7 in mark_object (arg=172893790) at alloc.c:5577 >> 5577 FLOAT_MARK (XFLOAT (obj)); > > Ouch! > >> (gdb) bt full >> #0 0x081903b7 in mark_object (arg=172893790) at alloc.c:5577 >> obj = <value optimized out> > > How come values are "optimized out" when you compiled without > optimizations? Can you show a sample GCC compilation command line > from the build process, with all its switches? Because i forget to run ./configure with CFLAGS. > Also, please type "source /path/to/src/.gdbinit" at GDB's prompt > (where "/path/to/src/" is the Emacs src directory), and then type > "xbacktrace", to show the Lisp-level backtrace. Now really compiled with no optimizations, CFLAGS='-O0 -g -pipe' i have no crashs since two days... -- A+ Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997 ^ permalink raw reply [flat|nested] 48+ messages in thread
end of thread, other threads:[~2010-12-28 13:14 UTC | newest] Thread overview: 48+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-09-24 17:53 bug#7098: Emacs24 crash with segmentation fault Thierry Volpiatto 2010-09-24 18:18 ` Eli Zaretskii 2010-09-24 19:14 ` Eli Zaretskii 2010-09-24 19:32 ` Thierry Volpiatto 2010-09-24 19:48 ` Eli Zaretskii 2010-09-27 8:54 ` Thierry Volpiatto 2010-09-27 10:53 ` Eli Zaretskii 2010-09-27 12:43 ` Thierry Volpiatto 2010-09-27 13:56 ` Eli Zaretskii 2010-09-27 14:06 ` Thierry Volpiatto 2010-09-27 15:43 ` Eli Zaretskii 2010-09-28 7:48 ` Thierry Volpiatto 2010-09-24 19:23 ` Thierry Volpiatto 2010-09-24 19:36 ` Eli Zaretskii 2010-09-24 19:58 ` Thierry Volpiatto 2010-09-24 20:14 ` Eli Zaretskii 2010-09-25 7:40 ` Thierry Volpiatto 2010-09-25 8:10 ` Eli Zaretskii 2010-09-25 8:23 ` Thierry Volpiatto 2010-09-25 9:25 ` Juanma Barranquero 2010-09-25 9:35 ` Thierry Volpiatto 2010-09-25 11:13 ` Juanma Barranquero 2010-09-25 11:39 ` Thierry Volpiatto 2010-09-25 11:59 ` Eli Zaretskii 2010-09-25 12:32 ` Thierry Volpiatto 2010-09-25 21:26 ` Thierry Volpiatto 2010-09-26 5:25 ` Thierry Volpiatto 2010-09-25 12:01 ` Juanma Barranquero 2010-09-25 12:45 ` Thierry Volpiatto 2010-09-25 20:45 ` Juanma Barranquero 2010-12-06 20:39 ` Chong Yidong 2010-12-06 21:15 ` Thierry Volpiatto 2010-12-09 7:25 ` Thierry Volpiatto 2010-12-15 1:50 ` Chong Yidong 2010-12-15 6:46 ` Thierry Volpiatto 2010-12-16 1:15 ` Chong Yidong 2010-12-16 8:03 ` Thierry Volpiatto 2010-12-16 17:35 ` Eli Zaretskii 2010-12-16 18:07 ` Thierry Volpiatto 2010-12-16 18:10 ` Eli Zaretskii 2010-12-16 18:43 ` Thierry Volpiatto 2010-12-16 19:25 ` Eli Zaretskii 2010-12-16 19:36 ` Thierry Volpiatto 2010-12-18 7:24 ` Thierry Volpiatto 2010-12-18 9:16 ` Thierry Volpiatto 2010-12-18 10:08 ` Eli Zaretskii 2010-12-21 11:34 ` Thierry Volpiatto 2010-12-28 13:14 ` Thierry Volpiatto
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.