Bug 36037 - [4.4 regression] segfault in gt_ggc_mx_dw_loc_descr_struct
Summary: [4.4 regression] segfault in gt_ggc_mx_dw_loc_descr_struct
Status: RESOLVED WORKSFORME
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.4.0
: P2 normal
Target Milestone: 4.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords: GC, ice-on-valid-code
Depends on:
Blocks: 29975
  Show dependency treegraph
 
Reported: 2008-04-24 14:46 UTC by Francois-Xavier Coudert
Modified: 2008-07-03 06:09 UTC (History)
3 users (show)

See Also:
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Francois-Xavier Coudert 2008-04-24 14:46:56 UTC
Downloading the code at http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz, uncompressing it and compiling it with mainline GCC on x86_64-linux at -O2 -g gives:

Program received signal SIGSEGV, Segmentation fault.
0x000000000053f99d in gt_ggc_mx_dw_loc_descr_struct (x_p=0x2aaae3061fa0)
    at ./gt-dwarf2out.h:214
warning: Source file is more recent than executable.
214       if (ggc_test_and_set_mark (x))
(gdb) p x
$1 = (struct dw_loc_descr_struct * const) 0x2aaae3061fa0
(gdb) p *x
$2 = {dw_loc_next = 0x0, dw_loc_opc = DW_OP_ne, dw_loc_oprnd1 = {
    val_class = dw_val_class_unsigned_const, v = {val_addr = 0x0,
      val_offset = 0, val_loc_list = 0x0, val_loc = 0x0, val_int = 0,
      val_unsigned = 0, val_long_long = {hi = 0, low = 0}, val_vec = {
        array = 0x0, length = 0, elt_size = 0}, val_die_ref = {die = 0x0,
        external = 0}, val_fde_index = 0, val_str = 0x0, val_lbl_id = 0x0,
      val_flag = 0 '\0', val_file = 0x0}}, dw_loc_oprnd2 = {
    val_class = dw_val_class_unsigned_const, v = {val_addr = 0x0,
      val_offset = 0, val_loc_list = 0x0, val_loc = 0x0, val_int = 0,
      val_unsigned = 0, val_long_long = {hi = 0, low = 0}, val_vec = {
        array = 0x0, length = 0, elt_size = 0}, val_die_ref = {die = 0x0,
        external = 0}, val_fde_index = 0, val_str = 0x0, val_lbl_id = 0x0,
      val_flag = 0 '\0', val_file = 0x0}}, dw_loc_addr = 0}
(gdb) bt
#0  0x000000000053f99d in gt_ggc_mx_dw_loc_descr_struct (x_p=0x2aaae3061fa0)
    at ./gt-dwarf2out.h:214
#1  0x000000000053f9b5 in gt_ggc_mx_dw_loc_descr_struct (x_p=0x2aaae3061f50)
    at ./gt-dwarf2out.h:216
#2  0x000000000053f9b5 in gt_ggc_mx_dw_loc_descr_struct (x_p=0x2aaae3061f00)
    at ./gt-dwarf2out.h:216
#3  0x000000000053f9b5 in gt_ggc_mx_dw_loc_descr_struct (x_p=0x2aaae3061eb0)
    at ./gt-dwarf2out.h:216
#4  0x000000000053fd03 in gt_ggc_mx_VEC_dw_attr_node_gc (
    x_p=<value optimized out>) at ./gt-dwarf2out.h:96
#5  0x000000000053fd4d in gt_ggc_mx_die_struct (x_p=0x2aaae305c8a0)
    at ./gt-dwarf2out.h:361
#6  0x000000000047ed4d in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>)
    at ./gt-fortran-f95-lang.h:325
#7  0x000000000047e9db in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>)
    at ./gt-fortran-f95-lang.h:333


The exact command-line used is "./f951 -fmem-report all_cp2k_gfortran.f90 -O2 -g". Probably a middle-end or garbage collection issue as it goes fine with -O0.

I'm not sure whether this passes for GCC 4.3.0, but I know it used to pass before 4.4 was branched off.
Comment 1 Joost VandeVondele 2008-05-07 08:45:52 UTC
here things appear to work ? What are the numbers you have for '--param ggc-min-expand=30 --param ggc-min-heapsize=4096' ?

> gfortran -c -O2 -g -fmem-report all.f90
Memory still allocated at the end of the compilation process
Size   Allocated        Used    Overhead
8           4096          16         120
16            13M       1668k        304k
128         4044k        675k         55k
256         4068k       3349k         55k
512          252M        227M       3541k
1024          16k       6144         224
2048          28k         16k        392
4096         684k        684k       9576
8192          32k         32k        224
16384         32k         32k        112
32768         32k         32k         56
65536        128k        128k        112
131072        512k        512k        224
262144        768k        768k        168
524288       2048k       2048k        224
1048576       3072k       3072k        168
4194304       4096k       4096k         56
8388608       8192k       8192k         56
192          115M        101M       1613k
160           79M         64M       1109k
144           11M       6162k        158k
96           132M         71M       1861k
48           150M         80M       2403k
208           38M         35M        533k
64            31M       1683k        499k
32           103M       9308k       1866k
80           278M         54M       3900k
Total       1234M        678M         17M

String pool
entries         1324233
identifiers     1324233 (100.00%)
slots           2097152
bytes           14M (1384k overhead)
table size      16M
coll/search     0.5910
ins/search      0.0865
avg. entry      11.43 bytes (+/- 4.53)
longest entry   68

??? tree nodes created

(No per-node statistics)
Type hash: size 131071, 71937 elements, 1.616711 collisions
DECL_DEBUG_EXPR  hash: size 65521, 22 elements, 0.439186 collisions
DECL_VALUE_EXPR  hash: size 1021, 19 elements, 0.000000 collisions
Comment 2 Francois-Xavier Coudert 2008-05-07 10:17:19 UTC
OK, well, it was 100% reproducible two weeks ago, but I can't see it happening anymore on trunk. Closing.
Comment 3 Joost VandeVondele 2008-05-18 17:52:09 UTC
I think this bug is back. Current gfortran fails again with:

(gdb) run all.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase all.f90 -auxbase all -O3 -version -ffast-math -ftree-vectorize -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude -o /tmp/ccJOx9ry.s
Starting program: /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951 all.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase all.f90 -auxbase all -O3 -version -ffast-math -ftree-vectorize -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude -o /tmp/ccJOx9ry.s
GNU Fortran (GCC) version 4.4.0 20080518 (experimental) [trunk revision 135494] (x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.4.0 20080518 (experimental) [trunk revision 135494], GMP version 4.2.1, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

Program received signal SIGSEGV, Segmentation fault.
ggc_set_mark (p=0x200000000) at /data03/vondele/gcc_trunk/gcc/gcc/ggc-page.c:584
584       while (table->high_bits != high_bits)
(gdb) bt
#0  ggc_set_mark (p=0x200000000) at /data03/vondele/gcc_trunk/gcc/gcc/ggc-page.c:584
#1  0x0000000000485568 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:49
#2  0x000000000048667f in gt_ggc_mx_lang_type (x_p=<value optimized out>) at ./gtype-fortran.h:64
#3  0x0000000000485b24 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:338
#4  0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#5  0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#6  0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#7  0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#8  0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#9  0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#10 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#11 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#12 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#13 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#14 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#15 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#16 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#17 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#18 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#19 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#20 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#21 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#22 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#23 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#24 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#25 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#26 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#27 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#28 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#29 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#30 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#31 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#32 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#33 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#34 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#35 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#36 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#37 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#38 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#39 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#40 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#41 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#42 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#43 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
#44 0x0000000000485acb in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:333
[...]
Comment 4 Joost VandeVondele 2008-05-18 17:59:06 UTC
the end of the backtrace (notice the depth) might be useful as well:

#78681 0x0000000000486421 in gt_ggc_mx_lang_tree_node (x_p=<value optimized out>) at ./gt-fortran-f95-lang.h:290
#78682 0x0000000000632f85 in gt_ggc_mx_cgraph_node (x_p=<value optimized out>) at gtype-desc.c:161
#78683 0x0000000000633236 in gt_ggc_m_P11cgraph_node4htab (x_p=<value optimized out>) at gtype-desc.c:1852
#78684 0x000000000061203f in ggc_mark_roots () at /data03/vondele/gcc_trunk/gcc/gcc/ggc-common.c:104
#78685 0x00000000004d0279 in ggc_collect () at /data03/vondele/gcc_trunk/gcc/gcc/ggc-page.c:1895

#78686 0x000000000067a235 in execute_todo (flags=34871) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1051
#78687 0x000000000067a4c4 in execute_one_pass (pass=0xf16380) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1307
#78688 0x000000000067a6a5 in execute_pass_list (pass=0xf16380) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1335
#78689 0x000000000067a6bd in execute_pass_list (pass=0xf15ea0) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1336
#78690 0x000000000067a99e in execute_ipa_pass_list (pass=0xf15e40) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:892
#78691 0x000000000091a76d in cgraph_optimize () at /data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1336
#78692 0x0000000000484e65 in gfc_be_parse_file (set_yydebug=<value optimized out>)
    at /data03/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:262
#78693 0x00000000006ffa68 in toplev_main (argc=<value optimized out>, argv=<value optimized out>)
    at /data03/vondele/gcc_trunk/gcc/gcc/toplev.c:963
#78694 0x00002b0d19a7c154 in __libc_start_main () from /lib64/libc.so.6
Comment 5 Joost VandeVondele 2008-05-30 07:40:25 UTC
A few days ago I started a compilation with
vondele@pcihopt3:/data03/vondele/gcc_trunk/CP2K_gcc_2007_06/src> gfortran -v  -c --param ggc-min-expand=0 --param ggc-min-heapsize=4096 -O3 -ffast-math -ftree-vectorize -march=native all.f90

which lead to 

Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /data03/vondele/gcc_trunk/gcc/configure --prefix=/data03/vondele/gcc_trunk/build --with-gmp=/data03/vondele/ --with-mpfr=/data03/vondele/ --enable-languages=c,fortran
Thread model: posix
gcc version 4.4.0 20080520 (experimental) [trunk revision 135667] (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '--param' 'ggc-min-expand=0' '--param' 'ggc-min-heapsize=4096' '-O3' '-ffast-math' '-ftree-vectorize'
 /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951 all.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase all.f90 -auxbase all -O3 -version -ffast-math -ftree-vectorize --param ggc-min-expand=0 --param ggc-min-heapsize=4096 -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude -o /tmp/ccMREBre.s
GNU Fortran (GCC) version 4.4.0 20080520 (experimental) [trunk revision 135667] (x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.4.0 20080520 (experimental) [trunk revision 135667], GMP version 4.2.1, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=0 --param ggc-min-heapsize=4096
all.f90: In function ‘spme_coeff_calculate’:
all.f90:477078: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

I'm wondering if that now could point more accurately to the point of failure?
Just compiling the offending module with these options is not enough.

I'd like to help debugging this, but I would need some hints on how to do this...


Comment 6 Richard Biener 2008-06-25 12:01:12 UTC
It looks like you run out of stack space during GC walk.  You can check if so
by raising the stack limit with 'ulimit -s unlimited'.

I recall that Jakub had a patch to limit recursion in GC somewhat?
Comment 7 Jakub Jelinek 2008-06-25 12:06:02 UTC
That was PR36060 and is already fixed in 4.3/4.4.
Comment 8 Joost VandeVondele 2008-06-30 06:22:53 UTC
(In reply to comment #6)
> It looks like you run out of stack space during GC walk.  You can check if so
> by raising the stack limit with 'ulimit -s unlimited'.

current trunk (actually a few days old) doesn't fail anymore. The script used for testing actually has ulimit -s 128000 which is pretty high. I tested with ulimit -s 32000 and ulimit -s 64000, but couldn't get a crash.

Comment 9 Uroš Bizjak 2008-07-03 06:09:55 UTC
(In reply to comment #8)

> current trunk (actually a few days old) doesn't fail anymore. The script used
> for testing actually has ulimit -s 128000 which is pretty high. I tested with
> ulimit -s 32000 and ulimit -s 64000, but couldn't get a crash.

Closed (again) as WORKSFORME.