GNU bug report logs - #7098
Emacs24 crash with segmentation fault

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7098 in the body.
You can then email your comments to 7098 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Emacs24 crash with segmentation fault
Date: Fri, 24 Sep 2010 19:53:28 +0200

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 

Message #8 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Fri, 24 Sep 2010 20:18:50 +0200

> From: Thierry Volpiatto <thierry.volpiatto <at> 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?

Message #11 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: thierry.volpiatto <at> gmail.com, 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Fri, 24 Sep 2010 21:14:52 +0200

> Date: Fri, 24 Sep 2010 20:18:50 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 7098 <at> 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?

Message #14 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Fri, 24 Sep 2010 21:23:09 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto <at> 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 <at> 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 

Message #17 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Fri, 24 Sep 2010 21:32:26 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Fri, 24 Sep 2010 20:18:50 +0200
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: 7098 <at> 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 

Message #20 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Fri, 24 Sep 2010 21:36:47 +0200

> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> Cc: 7098 <at> 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

Message #23 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Fri, 24 Sep 2010 21:48:35 +0200

> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> Cc: 7098 <at> 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

Message #26 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Fri, 24 Sep 2010 21:58:36 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>> Cc: 7098 <at> 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 

Message #29 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Fri, 24 Sep 2010 22:14:40 +0200

> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> Cc: 7098 <at> 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.

Message #32 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Sat, 25 Sep 2010 09:40:55 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>> Cc: 7098 <at> 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 <at> 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 

Message #35 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Sat, 25 Sep 2010 10:10:32 +0200

> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> Cc: 7098 <at> 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.

Message #38 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Sat, 25 Sep 2010 10:23:44 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>> Cc: 7098 <at> 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 

Message #41 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Sat, 25 Sep 2010 11:25:37 +0200

On Sat, Sep 25, 2010 at 10:23, Thierry Volpiatto
<thierry.volpiatto <at> 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

Message #44 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Sat, 25 Sep 2010 11:35:06 +0200

Juanma Barranquero <lekktu <at> gmail.com> writes:

> On Sat, Sep 25, 2010 at 10:23, Thierry Volpiatto
> <thierry.volpiatto <at> 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 

Message #47 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Sat, 25 Sep 2010 13:13:40 +0200

On Sat, Sep 25, 2010 at 11:35, Thierry Volpiatto
<thierry.volpiatto <at> 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

Message #50 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Sat, 25 Sep 2010 13:39:05 +0200

Juanma Barranquero <lekktu <at> gmail.com> writes:

> On Sat, Sep 25, 2010 at 11:35, Thierry Volpiatto
> <thierry.volpiatto <at> 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 <at> 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 

Message #53 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: lekktu <at> gmail.com, 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Sat, 25 Sep 2010 13:59:13 +0200

> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  7098 <at> 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.

Message #56 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Sat, 25 Sep 2010 14:01:07 +0200

On Sat, Sep 25, 2010 at 13:39, Thierry Volpiatto
<thierry.volpiatto <at> 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

Message #59 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Sat, 25 Sep 2010 14:32:24 +0200

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  7098 <at> 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 

[traverselisp.el (application/emacs-lisp, attachment)]

Message #62 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Sat, 25 Sep 2010 14:45:02 +0200

Juanma Barranquero <lekktu <at> gmail.com> writes:

> On Sat, Sep 25, 2010 at 13:39, Thierry Volpiatto
> <thierry.volpiatto <at> 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 

Message #65 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Sat, 25 Sep 2010 22:45:45 +0200

On Sat, Sep 25, 2010 at 14:45, Thierry Volpiatto
<thierry.volpiatto <at> 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

Message #68 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Sat, 25 Sep 2010 23:26:37 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  7098 <at> 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 <at> 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 <at> 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 

Message #71 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Sun, 26 Sep 2010 07:25:58 +0200

[Message part 1 (text/plain, inline)]

Thierry Volpiatto <thierry.volpiatto <at> gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  7098 <at> 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 <at> 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 <at> 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 <at> 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 

[debug-emacs-bt-full.txt (text/plain, attachment)]

Message #74 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Mon, 27 Sep 2010 10:54:25 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Fri, 24 Sep 2010 20:18:50 +0200
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: 7098 <at> 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 

Message #77 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Mon, 27 Sep 2010 06:53:09 -0400

> From: Thierry Volpiatto <thierry.volpiatto <at> 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.

Message #80 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Mon, 27 Sep 2010 14:43:30 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto <at> 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 

Message #83 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Mon, 27 Sep 2010 09:56:26 -0400

> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> Date: Mon, 27 Sep 2010 14:43:30 +0200
> Cc: 
> 
> Eli Zaretskii <eliz <at> 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.

Message #86 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Mon, 27 Sep 2010 16:06:49 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>> Date: Mon, 27 Sep 2010 14:43:30 +0200
>> Cc: 
>> 
>> Eli Zaretskii <eliz <at> 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 

Message #89 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Mon, 27 Sep 2010 11:43:45 -0400

> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> Cc: bug-gnu-emacs <at> 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.

Message #92 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Tue, 28 Sep 2010 09:48:05 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>> Cc: bug-gnu-emacs <at> 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 

Message #95 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: 7098 <at> debbugs.gnu.org
Subject: Re: Emacs24 crash with segmentation fault
Date: Mon, 06 Dec 2010 15:39:18 -0500

> 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?

Message #98 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Mon, 06 Dec 2010 22:15:46 +0100

Chong Yidong <cyd <at> 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 

Message #101 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 7098 <at> debbugs.gnu.org
Subject: Re: Emacs24 crash with segmentation fault
Date: Thu, 09 Dec 2010 08:25:06 +0100

Chong Yidong <cyd <at> 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 

Message #104 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: 7098 <at> debbugs.gnu.org
Subject: Re: Emacs24 crash with segmentation fault
Date: Wed, 15 Dec 2010 09:50:16 +0800

Thierry Volpiatto <thierry.volpiatto <at> 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?

Message #107 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 7098 <at> debbugs.gnu.org
Subject: Re: Emacs24 crash with segmentation fault
Date: Wed, 15 Dec 2010 07:46:05 +0100

Chong Yidong <cyd <at> stupidchicken.com> writes:

> Thierry Volpiatto <thierry.volpiatto <at> 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 

Message #110 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: 7098 <at> debbugs.gnu.org
Subject: Re: Emacs24 crash with segmentation fault
Date: Thu, 16 Dec 2010 09:15:34 +0800

Thierry Volpiatto <thierry.volpiatto <at> 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.

Message #113 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 7098 <at> debbugs.gnu.org
Subject: Re: Emacs24 crash with segmentation fault
Date: Thu, 16 Dec 2010 09:03:54 +0100

Chong Yidong <cyd <at> stupidchicken.com> writes:

> Thierry Volpiatto <thierry.volpiatto <at> 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 

Message #116 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: cyd <at> stupidchicken.com, 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Thu, 16 Dec 2010 19:35:18 +0200

> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> Date: Thu, 16 Dec 2010 09:03:54 +0100
> Cc: 7098 <at> 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?

Message #119 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cyd <at> stupidchicken.com, 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Thu, 16 Dec 2010 19:07:13 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>> Date: Thu, 16 Dec 2010 09:03:54 +0100
>> Cc: 7098 <at> 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 

Message #122 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: cyd <at> stupidchicken.com, 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Thu, 16 Dec 2010 20:10:09 +0200

> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> Cc: cyd <at> stupidchicken.com,  7098 <at> 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?

Message #125 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cyd <at> stupidchicken.com, 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Thu, 16 Dec 2010 19:43:09 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>> Cc: cyd <at> stupidchicken.com,  7098 <at> 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 

Message #128 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: cyd <at> stupidchicken.com, 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Thu, 16 Dec 2010 21:25:14 +0200

> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
> Cc: cyd <at> stupidchicken.com,  7098 <at> 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"

Message #131 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cyd <at> stupidchicken.com, 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Thu, 16 Dec 2010 20:36:58 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>> Cc: cyd <at> stupidchicken.com,  7098 <at> 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 

Message #134 received at 7098 <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cyd <at> stupidchicken.com, 7098 <at> debbugs.gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Sat, 18 Dec 2010 08:24:09 +0100

Hi Eli,

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>> Cc: cyd <at> stupidchicken.com,  7098 <at> 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 

Message #137 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Sat, 18 Dec 2010 10:16:10 +0100

Thierry Volpiatto <thierry.volpiatto <at> gmail.com> writes:

> Hi Eli,
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>>> Cc: cyd <at> stupidchicken.com,  7098 <at> 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 

Message #140 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Sat, 18 Dec 2010 12:08:11 +0200

> From: Thierry Volpiatto <thierry.volpiatto <at> 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.

Message #143 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Tue, 21 Dec 2010 12:34:38 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto <at> 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 

Message #146 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#7098: Emacs24 crash with segmentation fault
Date: Tue, 28 Dec 2010 14:14:01 +0100

Hi Eli,

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto <at> 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 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.