Re: Fwd: Re: GC crashes

Re: Fwd: Re: GC crashes

[Chong Yidong]

I've been following up on the crashes reported at
(http://lists.gnu.org/archive/html/emacs-devel/2005-10/msg01325.html)
by Friedrich Delgado Friedrichs.  I noticed he was also using
hyperthreading.

>> By the way, could you tell me what `uname -a' returns, and your gcc
>> version?
>
> Linux kermit 2.6.13-15-smp #1 SMP Tue Sep 13 14:56:15 UTC 2005 i686 i686 i386 GNU/Linux
>
> (the smp is due to hyperthreading)
>
> gcc (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux)

Is anyone else on this list using Pentium 4 hyperthreading with gcc
4.0.2?

Re: Fwd: Re: GC crashes

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> I've been following up on the crashes reported at
> (http://lists.gnu.org/archive/html/emacs-devel/2005-10/msg01325.html)
> by Friedrich Delgado Friedrichs.  I noticed he was also using
> hyperthreading.
>
>>> By the way, could you tell me what `uname -a' returns, and your
>>> gcc version?
>>
>> Linux kermit 2.6.13-15-smp #1 SMP Tue Sep 13 14:56:15 UTC 2005 i686
>> i686 i386 GNU/Linux
>>
>> (the smp is due to hyperthreading)

I noticed also that another string_free_list crash, reported in April,
occurred in a system with hyperthreading as well:

http://lists.gnu.org/archive/html/bug-gnu-emacs/2005-04/msg00027.html

System: Suse Linux 9.1 on Pentium 4 with 2 GB RAM.
Suse kernel 2.6.5-7.145-smp #1 SMP.

I've asked Friedrich to check if the crashes go away with
hyperthreading turned off.  If so, this may be a Linux bug, or a GCC
bug.

Re: Fwd: Re: GC crashes

[Richard M. Stallman]

    I've asked Friedrich to check if the crashes go away with
    hyperthreading turned off.  If so, this may be a Linux bug, or a GCC
    bug.

This is useful progress.  It sure seems to explain why the bug
never happens for most of us.  However, it does not directly
help us localize and fix the bug.

If we determine that the bug happens with certain versions of GCC
and not with certain other versions, that would help more.
Because then it would be possible to compile some files with each
GCC version, and thus determine which file is at fault.
Then, by splitting that file in different places, it would be
possible to determine which function is at fault.  Then
comparing the assembler code made from that function by the two
GCC versions one might spot the bug.

There's no way to use the hyperthreading variable to do this
because we can't run some files with hyperthreading and some files
without.