Re: issue with gcc 4.x optimizations

[Martin Quinson <martin.quinson@loria.fr>]

[-- 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 --]