issue with gcc 4.x optimizations

issue with gcc 4.x optimizations

[Martin Quinson]

[-- Attachment #1: Type: text/plain, Size: 3185 bytes --]

Hello,

I come to you because I have an issue regarding gcc optimization in the 4.x
branch which really puzzles me. 

I have a rather big program here which compiles perfectly on a whole bunch
of architectures (x86, amd64, ppc, sparc, ...) with older versions (3.3,
3.4) with -O3 -fno-strict-aliasing. It even works with 2.9-aix51-020209 on
AIX ;) It also works with 4.0 and 4.1 with -O0 (tested only on x86).

But it fails as soon as I use -O1 on v4.x. It even fails with
   -O1 -fno-defer-pop -fno-guess-branch-probability -fno-cprop-registers
   -fno-loop-optimize -fno-if-conversion -fno-if-conversion2
   -fno-merge-constants -fno-tree-ccp -fno-tree-dce -fno-tree-dominator-opts
   -fno-tree-dse -fno-tree-ter -fno-tree-lrs -fno-tree-sra
   -fno-tree-copyrename -no-ftree-fre -fno-tree-ch -fno-delayed-branch
According to the documentation, this should be very close to -O0 since I
disable all the flags enabled by -O1. The difference should come from what
the documentation implies when stating: "Not all optimizations are
controlled directly by a flag. Only optimizations that have a flag are
listed". I guess that my problem comes from one of the not listed
optimizations.

The symptoms are a segfault near the end of the program with the following
valgrind backtrace:
==13387== Jump to the invalid address stated on the next line
==13387==    at 0x34938BFF: ???
==13387==    by 0x406602F: gras_process_exit (rl_process.c:23)
==13387==    by 0x40450EE: gras_exit (gras.c:74)
==13387==    by 0x804E216: main (datadesc_usage.c:662)
==13387==  Address 0x34938BFF is not stack'd, malloc'd or (recently) free'd
==13387==
==13387== Process terminating with default action of signal 11 (SIGSEGV)
==13387==  Access not within mapped region at address 0x34938BFF
==13387==    at 0x34938BFF: ???
==13387==    by 0x406602F: gras_process_exit (rl_process.c:23)
==13387==    by 0x40450EE: gras_exit (gras.c:74)
==13387==    by 0x804E216: main (datadesc_usage.c:662)
==13387==
==13387== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 21 from 2)

Here is the code of gras_process_exit():
void gras_process_exit() {
  gras_procdata_exit();
  free(_gras_procdata);
}
Line 23 of this file is the call to gras_procdata_exit(). As you can see,
there is no reason for this call to get unresolved by valgrind. Why "???" ?
And moreover, why 0x34938BFF? It seems a bit strange to me (too far from the
other addresses).



If someone wants to play with the code, it's available from our CVS here:
cvs -d :pserver:anonymous@scm.gforge.inria.fr:/cvsroot/simgrid co simgrid
but 20000 lines are ways too much for a proper bug repport, I guess. 

I write to this mailing list because I have no idea of where to look at. I
just wanted to check if someone already experienced something like that
before.


If someone can help me, that would be just wonderful. If not, I'm doomed to
3.x versions...

Thanks in advance,
Mt.

PS: please CC me as I'm not on the list yet.

-- 
Oh, I am a C programmer and I'm okay.
I muck with indices and structs all day.
And when it works, I shout hoo-ray.
Oh, I am a C programmer and I'm okay.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: issue with gcc 4.x optimizations

[Andrew Haley]

Martin Quinson writes:

 > I write to this mailing list because I have no idea of where to look at. I
 > just wanted to check if someone already experienced something like that
 > before.

I'm sure that every C programmer has experienced something like this
before.  What happened when you looked at your program with gdb?

Andrew.

Re: issue with gcc 4.x optimizations

[Ian Lance Taylor]

Martin Quinson <martin.quinson@loria.fr> writes:

> But it fails as soon as I use -O1 on v4.x. It even fails with
>    -O1 -fno-defer-pop -fno-guess-branch-probability -fno-cprop-registers
>    -fno-loop-optimize -fno-if-conversion -fno-if-conversion2
>    -fno-merge-constants -fno-tree-ccp -fno-tree-dce -fno-tree-dominator-opts
>    -fno-tree-dse -fno-tree-ter -fno-tree-lrs -fno-tree-sra
>    -fno-tree-copyrename -no-ftree-fre -fno-tree-ch -fno-delayed-branch
> According to the documentation, this should be very close to -O0 since I
> disable all the flags enabled by -O1.

-O1 enables a large number of optimizations which can not be turned
off using -f options.

Ian

Re: issue with gcc 4.x optimizations

[Martin Quinson]

[-- Attachment #1: Type: text/plain, Size: 4619 bytes --]

Andrew Haley writes:
> Martin Quinson writes:
>
> > I write to this mailing list because I have no idea of where to look at. I
> > just wanted to check if someone already experienced something like that
> > before.
>   
>  I'm sure that every C programmer has experienced something like this
>  before.  What happened when you looked at your program with gdb?
   
Sure. My guess is that I am playing some dangerous game fooling gcc here. My
only issue is that I have no clue of which one ;)

Here is the gdb backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x028bffff in ?? ()
(gdb) bt
#0  0x028bffff in ?? ()
#1  0xb7e3bfdc in gras_procdata_exit () at gras/Virtu/process.c:168
#2  0xb7e41797 in gras_process_exit () at gras/Virtu/rl_process.c:23
#3  0xb7e20935 in gras_exit () at gras/gras.c:74
#4  0x0804e20a in main (argc=Cannot access memory at address 0x3

It goes one level further than my previous tests which died right after the
gras_process_exit. This is with gcc 4.1.2 20060630 (prerelease) (Debian
4.1.1-6) while previously, I shown you what I get from 4.0.3 (Ubuntu
4.0.3-1ubuntu5) earlier today.

Here is the source of gras_procdata_exit():

gras_procdata_exit() {
  int len;

  while ((len=xbt_dynar_length(_gras_procdata_fabrics))) {
    xbt_dynar_remove_at(_gras_procdata_fabrics,len-1,NULL);
  }
}
	     
dynar are my dynamic array stuff (every C programmer has to come up with his
own dynamic array library, right?); we are here removing every elements of
the array called _gras_procdata_fabrics (in reverse order). Some printfs
show that we go one time through the loop, and it segfaults on the second
pass.

Note the really strange address of the called function at level 0 of the
backtrace. This is indeed what decided me to polute this list with my little
problems. It looks like something somewhere mangled it.

Here is the assembly code of the working version:
>>>>>>>>>>>>>>>>
gras_procdata_exit:
.LFB17:
        .loc 1 161 0
        pushl   %ebp
.LCFI40:
        movl    %esp, %ebp
.LCFI41:
        pushl   %ebx
.LCFI42:
        subl    $36, %esp
.LCFI43:
        call    __i686.get_pc_thunk.bx
        addl    $_GLOBAL_OFFSET_TABLE_, %ebx
        .loc 1 168 0
        jmp     .L83
.L84:
        .loc 1 169 0
        movl    -8(%ebp), %eax
        decl    %eax
        movl    _gras_procdata_fabrics@GOTOFF(%ebx), %edx
        movl    $0, 8(%esp)
        movl    %eax, 4(%esp)
        movl    %edx, (%esp)
        call    xbt_dynar_remove_at@PLT
.L83:
        .loc 1 168 0
        movl    _gras_procdata_fabrics@GOTOFF(%ebx), %eax
        movl    %eax, (%esp)
        call    xbt_dynar_length@PLT
        movl    %eax, -8(%ebp)
        cmpl    $0, -8(%ebp)
        jne     .L84
        .loc 1 172 0
        addl    $36, %esp
        popl    %ebx
        popl    %ebp
        ret
<<<<<<<<<<<<<<

And now the non-working (segfaulting) version:
>>>>>>>>>>>>>>
gras_procdata_exit:
.LFB50:
        .file 1 "gras/Virtu/process.c"
        .loc 1 161 0
        pushl   %ebp
.LCFI0:
        movl    %esp, %ebp
.LCFI1:
        pushl   %ebx
.LCFI2:
        call    __i686.get_pc_thunk.bx
        addl    $_GLOBAL_OFFSET_TABLE_, %ebx
        subl    $20, %esp
.LCFI3:
        jmp     .L2
        .p2align 4,,7
.L3:
        .loc 1 169 0
        decl    %eax
        xorl    %edx, %edx
        movl    %eax, 4(%esp)
        movl    _gras_procdata_fabrics@GOTOFF(%ebx), %eax
        movl    %edx, 8(%esp)
        movl    %eax, (%esp)
        call    xbt_dynar_remove_at@PLT
.L2:
        .loc 1 168 0
        movl    _gras_procdata_fabrics@GOTOFF(%ebx), %ecx
        movl    %ecx, (%esp)
        call    xbt_dynar_length@PLT
        testl   %eax, %eax
        jne     .L3
        .loc 1 172 0
        addl    $20, %esp
        popl    %ebx
        popl    %ebp
        ret
<<<<<<<<<<<<<<<<<

I'm really bad at reading assembly code, but it seems to me that the
non-working version is allocating 20 bytes on the stack where the working
one is using 32 bytes (please be patient if I'm saying stupidities here).

My issue may well be related to something else, but since the symptoms are
the same as for a stack overflow, this is my best current guess.

Any advice or hint would be deeply appreciated. Feel free to ask for more
information on need.
Mt.

PS: CC appreciated on answers, too.

-- 
Oh, I am a C programmer and I'm okay.
I muck with indices and structs all day.
And when it works, I shout hoo-ray.
Oh, I am a C programmer and I'm okay.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: issue with gcc 4.x optimizations

[Martin Quinson]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

For information, I've solved my issue. A part of my code was doing an
overflow in an array stored on the stack. It looks like %ebx is stored right
after user data, but only reused with dynamic linking and some optimizations
enabled (or so).

That is why it worked without optimization: I was overwritting a useless
value in that case.

Hoo-ray!

I am deeply sorry for this list polution.
Martin Quinson.

-- 
Oh, I am a C programmer and I'm okay.
I muck with indices and structs all day.
And when it works, I shout hoo-ray.
Oh, I am a C programmer and I'm okay.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: issue with gcc 4.x optimizations

[Andrew Haley]

Martin Quinson writes:
 > For information, I've solved my issue. A part of my code was doing an
 > overflow in an array stored on the stack. It looks like %ebx is stored right
 > after user data, but only reused with dynamic linking and some optimizations
 > enabled (or so).
 > 
 > That is why it worked without optimization: I was overwritting a useless
 > value in that case.
 > 
 > Hoo-ray!
 > 
 > I am deeply sorry for this list polution.

Thanks for letting us know.  FYI, -fstack-protector might have helped.

Andrew.