Re: [gentoo-user] SegFault while compiling gcc 4.1.1

[Vladimir G. Ivanovic]

Richard Fish wrote:
> On 11/30/06, Vladimir G. Ivanovic <vgivanovic@×××××××.net> wrote:
>> I have done nothing to my hardware and I've seen this error, oh, a
>> half a dozen times, the last time 3 months (?) ago. I ran memtest when
>> I installed new memory, and it did not report problems even when run
>> for hours.
>
> memtest is basically useless these days.  It can only tell you if you
> have a bad memory cell, which almost never happens today.  Most memory
> problems are the result of timing issues between the processor(s) and
> DMA controllers.
>
> This script [1] seems to be a much better memory test for modern
> systems, although you may have to make some tweaks to run it on
> Gentoo.

Just for kicks I'll run the script and see what happens.

>
>> And I do not get random segfaults with other programs.
>
> Yes, compiling is very unique in this regard.  The memory access
> pattern of a compiler, reading and writing to locations on different
> rows, or even different modules, under high CPU load and using lots of
> memory, with some IO thrown in for good measure, tends to reveal
> hardware problems quite nicely.
>
>> Finally, I don't think my hardware fixed itself.
>>
>> Given all of this, my suspicion is that these errors are software
>> bugs, not hardware problems.

For grins, here is part of comment #174:

	Random segfaults during compilation. ... in general a sign of
  	hardware problems.

	// No, this is in general a sign of GCC 4.1 - problem ;-)
>
> If we were talking about a driver, or an event-based GUI program, I
> might agree.  But a compiler is going to take the exact same actions
> given the same input and options.  The compiler isn't going to do
> something different between 2 different executions over the _exact_
> same sources because it feels like it.

You're right at the logical level, but not at the physical level. 
Cache effects and different disk accesses are two physical differences 
that spring to mind. Temporary files will be in different physical 
sectors, or in the buffer cache or not; directories may or may not be 
in the directory cache. Depending on what else is running, the pattern 
of cache misses will be different.

I emerge with -j2. Plus I'm doing work while the emerges happen. The 
likelihood of the memory access pattern of two compiles being the same 
is precisely zero.

>
>>
>> The other thing that I don't really believe is the part about "this
>> bug not being reproducible" as reported by portage/emerge/make/gcc.
>
> Then you should read the gcc sources.  One of the patches applied by
> Gentoo adds a retry loop when the compiler is about to exit with an
> internal compiler error (ICE).  It retries the compile twice, and if
> either of those succeeds, you get the "The bug is not reproducible"
> message.

Interesting. I did not know that. But I don't get why gcc exits with 
an error when the second (or third) try succeeds? Why not just print a 
warning, perhaps at the end so it is noticeable? Most people will 
restart the entire emerge, which seems like a gargantuan amount of 
wasted effort since the re-compilation has succeeded.

> It doesn't output anything because that would possibly
> obscure the original error.
>
> The gentoo devs probably added this loop to avoid more duplicates of [2].
>
> -Richard
>
> [1] http://people.redhat.com/dledford/memtest.html
> [2] http://bugs.gentoo.org/show_bug.cgi?id=20600

-- 
gentoo-user@g.o mailing list