On Mon, 11 Jul 2011 23:36:24 +0200, Sterling Augustine wrote:
> On head, synced this morning, I still get the failure.

OK, this is a different kind of crash than I reproduced before.
Re-posting back to the list with the off-list mail attached (+reformatted).

It is reproducible only for:
 * either cross-CU DIE reference by its offset but that is never produced by
   GCC so I do not consider it here.
 * or .debug_types, therefore -gdwarf-4 possibly with -fdebug-types-section.

And then also it must have:
 * missing DW_AT_MIPS_linkage_name which I guess only Google is using.
   One can simulate it in gdb by -ex 'set debug check-physname'.
   Otherwise C++ parameters printing would not get called.

And for the artificial reproducibility:
 * The referenced CUs must contain C++ parameters.
   To make possibly CTRL-C application while reading them in.
 * The referencing CU should not contain C++ parameters.
   Otherwise CTRL-C could apply too early.

Recommending some `ulimit -v 2000000' otherwise GDB can eat out the memory.

perl -le '$n=1000;print "class C$_ { public: void m (C$_ *c) {} } c$_;" for 1..$n;print "int main () { ";print "c$_.m (&c$_);" for 1..$n;print "}";'|g++ -gdwarf-4 -fdebug-types-section -Wall -x c++ -;./gdb -nx -ex 'set debug check-physname' ./a.out
g++ (GCC) 4.7.0 20110712 (experimental)
GNU gdb (GDB) 7.3.50.20110711-cvs
(gdb) b ^CQuit
(gdb) b <SEGV>
by:
(gdb) b <tab><fast ctrl-c>
(gdb) b <tab>

One can also use $n=10000 to have more than 1sec for <ctrl-c>.


> The segmentation fault happens because per_cu->cu == NULL.

While the fix is doing just the straightforward thing I do not see what better
fix could be made.


Thanks,
Jan


gdb/
2011-07-12  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Fix occasional crash of CTRL-C during DWARF read in.
	* dwarf2read.c (dwarf2_mark_helper): Return on NULL CU.

--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -15455,6 +15455,13 @@ dwarf2_mark_helper (void **slot, void *data)
   struct dwarf2_per_cu_data *per_cu;
 
   per_cu = (struct dwarf2_per_cu_data *) *slot;
+
+  /* cu->dependencies references may not yet have been ever read if QUIT aborts
+     reading of the chain.  As such dependencies remain valid there is not much
+     useful to track and undo them during QUIT cleanups.  */
+  if (per_cu->cu == NULL)
+    return 1;
+
   if (per_cu->cu->mark)
     return 1;
   per_cu->cu->mark = 1;