[Bug middle-end/56525] New: [4.8 Regression] Access to ggc_freed memory in flow_loops_find

jakub at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon Mar 4 17:51:00 GMT 2013


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56525

             Bug #: 56525
           Summary: [4.8 Regression] Access to ggc_freed memory in
                    flow_loops_find
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jakub@gcc.gnu.org


valgrind --track-origins=yes --leak-check=full --db-attach=yes ./cc1
/usr/src/gcc/gcc/testsuite/gcc.dg/torture/pr54458.c -O3 -fomit-frame-pointer -o
/tmp/x.s

fails with:
==2723== Invalid read of size 8
==2723==    at 0x670584: flow_loops_find(loops*) (cfgloop.c:445)
==2723==    by 0x8EC17E: fix_loop_structure(bitmap_head_def*) (loop-init.c:242)
==2723==    by 0xAA5F93: repair_loop_structures() (tree-cfgcleanup.c:716)
==2723==    by 0xAA602F: cleanup_tree_cfg() (tree-cfgcleanup.c:746)
==2723==    by 0x977221: execute_function_todo(void*) (passes.c:1921)
==2723==    by 0x97669A: do_per_function(void (*)(void*), void*)
(passes.c:1701)
==2723==    by 0x977476: execute_todo(unsigned int) (passes.c:1996)
==2723==    by 0x977E86: execute_one_pass(opt_pass*) (passes.c:2344)
==2723==    by 0x977FEB: execute_pass_list(opt_pass*) (passes.c:2378)
==2723==    by 0x97801C: execute_pass_list(opt_pass*) (passes.c:2379)
==2723==    by 0x97801C: execute_pass_list(opt_pass*) (passes.c:2379)
==2723==    by 0x696413: expand_function(cgraph_node*) (cgraphunit.c:1640)
==2723==  Address 0xb46b6f0 is not stack'd, malloc'd or (recently) free'd

This happens after unswitching pass, where a loop is first ggc_freed:
#1  0x00000000005fa4c8 in ggc_free (p=0x7ffff19896e8) at
../../gcc/ggc-page.c:1544
#2  0x000000000066fe08 in flow_loop_free (loop=0x7ffff19896e8) at
../../gcc/cfgloop.c:195
#3  0x00000000006721ca in delete_loop (loop=0x7ffff19896e8) at
../../gcc/cfgloop.c:1277
#4  0x00000000008ec13c in fix_loop_structure (changed_bbs=0x19162d0) at
../../gcc/loop-init.c:234
#5  0x0000000000aa5f94 in repair_loop_structures () at
../../gcc/tree-cfgcleanup.c:716
#6  0x0000000000aa6030 in cleanup_tree_cfg () at
../../gcc/tree-cfgcleanup.c:746

and then used in flow_loops_find:
443  /* The current active loop tree has valid loop-fathers for
444     header blocks.  */
445  if (!from_scratch
446      && header->loop_father->header == header)

When not under valgrind, header->loop_father->header will be typically
0xafafafafafafafaf, so won't match and show that it indeed does something
wrong.



More information about the Gcc-bugs mailing list