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:
signature.asc
Description: Digital signature
