Subject: Spurious(?) SEGV compiler errors?
To: None <current-users@NetBSD.org>
From: Havard Eidnes <he@NetBSD.org>
List: current-users
Date: 12/07/2007 03:07:46
Hi,

one of my i386 boxes continually run UPDATE builds of NetBSD-
current, itself running reasonably new -current code -- now most
recently updated to 4.99.40 as of three days ago.

Lately (not only after this upgrade) I've seen some of the builds
bomb out with SIGSEGV in the compiler.  When I repeat the compile
with "-v -save-temps", and re-run the cc1 process under the
debugger, it typically points towards parse_output_constraint() as
the culprit, ref. the stack backtrace below (though it's without
debugging info).

I've seen this problem at least in the sparc64 and the mipsco cross
compilers.

I've run 24h of memtest86 on this host, and it found no errors.
It's a 2x2.2GHz Xeon with 2GB of ECC memory.

Usually rebuilding the compiler in question from scratch "fixes" the
problem.  I've now also found that a sequence of

  "mv cc1 cc1.old; cp cc1.old cc1"

will also "fix" the problem.

First off, I'm wondering if anyone else is observing this problem.

Second, I'm wondering if this doesn't point towards something in the
VM subsystem as the culprit.

I find it really odd, though, that all diagnostics during compile
point to asm() constructs, and the debugger backtraces I"ve taken
the bother to collect also all point towards cc1's
parse_output_constraint().

So... "Strange!"

Here's the backtrace from a typical crash:

Program received signal SIGSEGV, Segmentation fault.
0x0823c329 in parse_output_constraint ()
(gdb) where
#0  0x0823c329 in parse_output_constraint ()
#1  0x0823f1d5 in expand_asm_operands ()
#2  0x0823fc89 in expand_asm_expr ()
#3  0x0816888b in expand_expr_real_1 ()
#4  0x08168bfb in expand_expr_real ()
#5  0x0823ec26 in expand_expr_stmt ()
#6  0x0826248f in expand_gimple_basic_block ()
#7  0x08262ed9 in tree_expand_cfg ()
#8  0x0825fb04 in execute_one_pass ()
#9  0x0825fba3 in execute_pass_list ()
#10 0x0809b86f in tree_rest_of_compilation ()
#11 0x080527b6 in c_expand_body ()
#12 0x0828ab7d in cgraph_expand_function ()
#13 0x0828b971 in cgraph_optimize ()
#14 0x08057387 in c_write_global_declarations ()
#15 0x082455f0 in toplev_main ()
#16 0x0808df2b in main ()
(gdb) quit

Hints appreciated, also for collecting more data about this.

Regards,

- H=E5vard