* 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 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: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: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: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: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: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 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 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-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-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 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.