Help tracing an internal compiler error

[Warren_Baird@cimmetry.com]

> Note that lookup_page_table_entry is inlined in ggc_set_mark so the line
> numbering may not exactly match that of the original source code. I think
> the segfault actually occurs at the next line:
>
>   return base[L1][L2];
>
> > *****
> > Here's the traceback...  It's pretty deep --- could this be a stack
> > overflow?
>
> That would be coherent with my previous remark: base is allocated in a page
> that the process isn't allowed to access.
>
> The default maximum stack size is 8192K on Solaris 2.7 and 2.8, try to bump
> it to 16384K.

I tried setting it to 128MB yesterday, after I sent the email, and it made no
difference --- I also tried just unlimiting the stacksize.  I guess I should
have posted an update...

However,  I just fired up the debugger again to see if I can get any useful
information, and gdb is telling me that base is NULL...  which could have
something to do with it, if it isn't just gdb being confused by the
optimization...

(gdb) p base
$7 = (page_entry ***) 0x0
(gdb) p G
$9 = {pages = {0x0, 0x0, 0x0, 0x98b820, 0x98ac88, 0xbc7060, 0x98ae48, 0x0,
    0xb25e18, 0xb65040, 0xb659a8, 0xb26c48, 0xb63fa0, 0xb650e0, 0xb28e20,
    0xb2bcc0, 0xb64fa0, 0x7a5e18, 0x4adb58, 0x0 <repeats 13 times>, 0x98ae10,
    0x0, 0x98afd0, 0x98add8}, page_tails = {0x0, 0x0, 0x0, 0x3dca00, 0x3defb0,
    0x3deec0, 0x3dee70, 0x0, 0x3c05e8, 0x3c09d0, 0x3c05c0, 0x3c0890, 0x3c08b8,
    0x3c0908, 0x3c08e0, 0x3c09f8, 0x3c0ac0, 0x4fbae8, 0x4adb58,
    0x0 <repeats 13 times>, 0x3dece0, 0x0, 0x3def60, 0x3dee20}, lookup = {
    0x0 <repeats 223 times>, 0xb3ace8, 0xa44790, 0xa21648, 0x9fd560, 0x9b3668,
    0x994008, 0x96c2e8, 0x5e9c00, 0x8b1260, 0x8725e0, 0x7d3c50, 0x79c8a0,
    0x7442d0, 0x717f18, 0x4a7138, 0x69f460, 0x678e08, 0x5090f8, 0x5ac4a8,
    0x495a88, 0x5286f8, 0x4e28c0, 0x4bfd10, 0x430940, 0x3dcaa8, 0x0, 0x0, 0x0,
    0x0, 0x0, 0x0, 0x0, 0x0}, pagesize = 8192, lg_pagesize = 13,
  allocated = 0, allocated_last_gc = 0, bytes_mapped = 268574720,
  context_depth_allocations = 1, context_depth_collections = 1,
  context_depth = 0, free_pages = 0x0, debug_file = 0x3604c8,
  depth_in_use = 1, depth_max = 10, depth = 0x3c2cc0, by_depth_in_use = 32630,
  by_depth_max = 32768, by_depth = 0x75c890, save_in_use = 0x77c898}

Also, I took a look at the isns gdb showed me:  The crash is happening at
0x254f58 --- Here's a few lines of isns on either side:

    0x254f44 <ggc_set_mark+40>:    sub  %g1, %o4, %g1
    0x254f48 <ggc_set_mark+44>:    sll  %l2, %g1, %g1
    0x254f4c <ggc_set_mark+48>:    add  %g1, -1, %g1
    0x254f50 <ggc_set_mark+52>:    and  %o5, %g1, %o5
    0x254f54 <ggc_set_mark+56>:    sll  %o5, 2, %o5
*** 0x254f58 <ggc_set_mark+60>:    ld  [ %o3 + %o5 ], %l3
    0x254f5c <ggc_set_mark+64>:    sethi  %hi(0x388800), %l1
    0x254f60 <ggc_set_mark+68>:    ldub  [ %l3 + 0x16 ], %l0
    0x254f64 <ggc_set_mark+72>:    ld  [ %l3 + 8 ], %g1
    0x254f68 <ggc_set_mark+76>:    or  %l1, 0x380, %l1
    0x254f6c <ggc_set_mark+80>:    sll  %l0, 3, %l0

I also set a breakpoint at this part of the code --- when it doesn't crash, I
saw some of the following values for the 3 registers used in the isn:

$o3 : 0x3e67a8, 0x98b690, 0x5bf950
$o5 :   0x146c,    0xe94,   0x17b4
$l3 : 0x3dcaa8, 0xb3ace8, 0x8b1260

but when it crashed, gdb shows all 3 registers as containing 0's...  I managed
to hit the breakpoint just before the crash, and it showed that ggc_set_mark was
called with p=0...  even though the previous traceback showed p=0xea7b70f8?  I'm
not sure what that means...  Aside from the the last call to ggc_set_mark, the
rest of the traceback looked similar.   I don't know if it is useful to post the
entire traceback again, so I'll put the first 15 stack frames here --- if you
want to see the rest, let me know...


(gdb) nexti

Program received signal SIGSEGV, Segmentation fault.
0x00254f58 in ggc_set_mark (p=0x0) at ../../gcc-3.3.1/gcc/ggc-page.c:525
12: /x $l3 = 0x0
11: /x $o5 = 0x0
10: /x $o3 = 0x0
(gdb) where
#0  0x00254f58 in ggc_set_mark (p=0x0) at ../../gcc-3.3.1/gcc/ggc-page.c:525
#1  0x00037360 in gt_ggc_mx_lang_tree_node (x_p=0x2000000) at gtype-cp.h:109
#2  0x00037310 in gt_ggc_mx_cxx_binding (x_p=0xe93d8390) at gtype-cp.h:92
#3  0x00037ebc in gt_ggc_mx_lang_tree_node (x_p=0xe93d83a8) at gtype-cp.h:322
#4  0x00037b14 in gt_ggc_mx_lang_tree_node (x_p=0xe9317e48) at gtype-cp.h:222
#5  0x00037ab4 in gt_ggc_mx_lang_tree_node (x_p=0xe931e180) at gtype-cp.h:218
#6  0x00037ac4 in gt_ggc_mx_lang_tree_node (x_p=0xe2faf100) at gtype-cp.h:218
#7  0x00037d14 in gt_ggc_mx_lang_tree_node (x_p=0xe2fb70f8) at gtype-cp.h:258
#8  0x00037c68 in gt_ggc_mx_lang_tree_node (x_p=0x2) at gtype-cp.h:269
#9  0x00037c68 in gt_ggc_mx_lang_tree_node (x_p=0x1) at gtype-cp.h:269
#10 0x00037c68 in gt_ggc_mx_lang_tree_node (x_p=0x1) at gtype-cp.h:269
#11 0x00037c68 in gt_ggc_mx_lang_tree_node (x_p=0x1) at gtype-cp.h:269
#12 0x00037784 in gt_ggc_mx_lang_tree_node (x_p=0xe9319080) at gtype-cp.h:193
#13 0x00037884 in gt_ggc_mx_lang_tree_node (x_p=0xe3040280) at gtype-cp.h:182
#14 0x00037844 in gt_ggc_mx_lang_tree_node (x_p=0xe931f400) at gtype-cp.h:182
#15 0x00037874 in gt_ggc_mx_lang_tree_node (x_p=0xe931f380) at gtype-cp.h:182

I think that's all the useful things I can think of doing at the moment...  If
you have any other suggestions, let me know...

Thanks,

Warren