|
From: Josef W. <Jos...@gm...> - 2004-09-13 12:29:46
|
Hi, I have a strange bug here. This was a bug report for calltree/callgrind, bu= t=20 it seems not to be a bug in my code, as it is happening with cachegrind, to= o. The bug reporter is running Valgrind 2.2.0 on Debian testing. The faulting address in the report below (0x3AA57282) is in the middle of a= =20 basic block with 11 instructions, as can be seen in debug output from=20 callgrind: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BB# 11326449 =2D setup_bbcc (BB 0x3AA57275): Instrs 11 (Len 34) log_1Dr: iaddr=3D0x3AA57275, isize=3D3, daddr=3D0x8160F50, dsize=3D4 log_0D: iaddr=3D0x3AA57278, isize=3D2 log_0D: iaddr=3D0x3AA5727A, isize=3D2 log_1Dr: iaddr=3D0x3AA5727C, isize=3D3, daddr=3D0x8160EE6, dsize=3D4 log_1Dr: iaddr=3D0x3AA5727F, isize=3D3, daddr=3D0x8160EEA, dsize=3D4 =3D=3D1258=3D=3D=20 =3D=3D1258=3D=3D Process terminating with default action of signal 11 (SIGS= EGV) =3D=3D1258=3D=3D Access not within mapped region at address 0xF30000C =3D=3D1258=3D=3D at 0x3AA57282: (within /lib/libc-2.3.2.so) =3D=3D1258=3D=3D by 0x3AA5607E: free (in /lib/libc-2.3.2.so) =3D=3D1258=3D=3D by 0x8050691: CBodyList_GetElem (cbody_list.c:126) =2E.. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =46rom further debug output, one can see that this BB maps to=20 libc-2.3.2.so +0x72275=3D0x3AA57275, and that is the relevant code: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > objdump -D --start-address=3D0x72270 /lib/libc-2.3.2.so|head -70 /lib/libc-2.3.2.so: file format elf32-i386 00072270 <.text+0x5c690>: 72270: 89 45 e8 mov %eax,0xffffffe8(%ebp) 72273: 75 13 jne 0x72288 72275: 8b 47 f8 mov 0xfffffff8(%edi),%eax 72278: 29 c1 sub %eax,%ecx 7227a: 01 c6 add %eax,%esi 7227c: 8b 51 08 mov 0x8(%ecx),%edx 7227f: 8b 41 0c mov 0xc(%ecx),%eax 72282: 89 42 0c mov %eax,0xc(%edx) <=3D SEGFAULT happening here 72285: 89 50 08 mov %edx,0x8(%eax) 72288: 8b 55 f0 mov 0xfffffff0(%ebp),%edx 7228b: 8b 7d ec mov 0xffffffec(%ebp),%edi 7228e: 3b 7a 54 cmp 0x54(%edx),%edi 72291: 0f 84 cb 00 00 00 je 0x72362 72297: 8b 45 e8 mov 0xffffffe8(%ebp),%eax 7229a: f6 44 38 04 01 testb $0x1,0x4(%eax,%edi,1) 7229f: 0f 85 ab 00 00 00 jne 0x72350 =2E.. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Interesting is that it also happens with "callgrind --simulate-cache=3Dno .= =2E.".=20 In this mode, I only have instrumented a call to a helper at the beginning = of=20 the BB. Thus, the segfault seems to be triggered by the valgrind generated= =20 code itself. Any idea how to track this down further? Josef Subject: Re: Bug#231095: valgrind-calltree: calltree terminates with SIGSEV= on=20 call to calloc. Date: Samstag, 11. September 2004 00:17 =46rom: Shan Mignot <sha...@fr...> To: Josef Weidendorfer <Jos...@gm...> I'm using: libc6 2.3.2ds1-1 from debian testing. My program is compiled with: gcc.real (GCC) 3.3.4 (Debian 1:3.3.4-6sarge1). I tried running callgrind without the cache simulation (callgring =2D-simulate-cache=3Dno) and running cachegrind (valgrind --tool=3Dcachegri= nd). Both segfault at precisely the same location ie: =3D=3D544=3D=3D Process terminating with default action of signal 11 (SIGSE= GV) =3D=3D544=3D=3D Access not within mapped region at address 0xF30000C =3D=3D544=3D=3D at 0x3AA57282: (within /lib/libc-2.3.2.so) =3D=3D544=3D=3D by 0x3AA5607E: free (in /lib/libc-2.3.2.so) =3D=3D544=3D=3D by 0x8050691: CBodyList_GetElem (cbody_list.c:126) Here's the dump from libc: > objdump -D --start-address=3D0x72270 /lib/libc-2.3.2.so|head -70 >| > libc.so.dump /lib/libc-2.3.2.so: file format elf32-i386 Disassembly of section .note.ABI-tag: Disassembly of section .hash: Disassembly of section .dynsym: Disassembly of section .dynstr: Disassembly of section .gnu.version: Disassembly of section .gnu.version_d: Disassembly of section .gnu.version_r: Disassembly of section .rel.dyn: Disassembly of section .rel.plt: Disassembly of section .plt: Disassembly of section .text: 00072270 <.text+0x5c690>: 72270: 89 45 e8 mov %eax,0xffffffe8(%ebp) 72273: 75 13 jne 0x72288 72275: 8b 47 f8 mov 0xfffffff8(%edi),%eax 72278: 29 c1 sub %eax,%ecx 7227a: 01 c6 add %eax,%esi 7227c: 8b 51 08 mov 0x8(%ecx),%edx 7227f: 8b 41 0c mov 0xc(%ecx),%eax 72282: 89 42 0c mov %eax,0xc(%edx) 72285: 89 50 08 mov %edx,0x8(%eax) 72288: 8b 55 f0 mov 0xfffffff0(%ebp),%edx 7228b: 8b 7d ec mov 0xffffffec(%ebp),%edi 7228e: 3b 7a 54 cmp 0x54(%edx),%edi 72291: 0f 84 cb 00 00 00 je 0x72362 72297: 8b 45 e8 mov 0xffffffe8(%ebp),%eax 7229a: f6 44 38 04 01 testb $0x1,0x4(%eax,%edi,1) 7229f: 0f 85 ab 00 00 00 jne 0x72350 722a5: 8b 47 0c mov 0xc(%edi),%eax 722a8: 8b 57 08 mov 0x8(%edi),%edx 722ab: 89 42 0c mov %eax,0xc(%edx) 722ae: 89 50 08 mov %edx,0x8(%eax) 722b1: 8b 45 e8 mov 0xffffffe8(%ebp),%eax 722b4: 01 c6 add %eax,%esi 722b6: 89 34 0e mov %esi,(%esi,%ecx,1) 722b9: 8b 45 f0 mov 0xfffffff0(%ebp),%eax 722bc: 83 c0 5c add $0x5c,%eax 722bf: 89 41 0c mov %eax,0xc(%ecx) 722c2: 8b 50 08 mov 0x8(%eax),%edx 722c5: 89 51 08 mov %edx,0x8(%ecx) 722c8: 89 48 08 mov %ecx,0x8(%eax) 722cb: 89 f0 mov %esi,%eax 722cd: 83 c8 01 or $0x1,%eax 722d0: 89 4a 0c mov %ecx,0xc(%edx) 722d3: 89 41 04 mov %eax,0x4(%ecx) 722d6: 81 fe ff ff 00 00 cmp $0xffff,%esi 722dc: 0f 86 6b ff ff ff jbe 0x7224d 722e2: 8b 55 f0 mov 0xfffffff0(%ebp),%edx 722e5: f6 42 28 01 testb $0x1,0x28(%edx) 722e9: 74 5b je 0x72346 722eb: 8d 83 70 0a 00 00 lea 0xa70(%ebx),%eax 722f1: 39 45 f0 cmp %eax,0xfffffff0(%ebp) 722f4: 74 1d je 0x72313 722f6: 8b 55 f0 mov 0xfffffff0(%ebp),%edx 722f9: 8b 42 54 mov 0x54(%edx),%eax 722fc: 8b 93 f4 0e 00 00 mov 0xef4(%ebx),%edx 72302: 83 c4 24 add $0x24,%esp 72305: 25 00 00 f0 ff and $0xfff00000,%eax 7230a: 5b pop %ebx 7230b: 5e pop %esi 7230c: 5f pop %edi 7230d: 5d pop %ebp 7230e: e9 ed cf ff ff jmp 0x6f300 72313: 8b 83 c4 0a 00 00 mov 0xac4(%ebx),%eax 72319: 8b 40 04 mov 0x4(%eax),%eax 7231c: 83 e0 f8 and $0xfffffff8,%eax Hope that helps. Please keep informed, I'd like to understand what is going on. Shan =2D------------------------------------------------------ |
|
From: Nicholas N. <nj...@ca...> - 2004-09-13 15:13:45
|
On Mon, 13 Sep 2004, Josef Weidendorfer wrote: > ==1258== Process terminating with default action of signal 11 (SIGSEGV) > ==1258== Access not within mapped region at address 0xF30000C > ==1258== at 0x3AA57282: (within /lib/libc-2.3.2.so) > ==1258== by 0x3AA5607E: free (in /lib/libc-2.3.2.so) > ==1258== by 0x8050691: CBodyList_GetElem (cbody_list.c:126) > [...] > Any idea how to track this down further? I'm happy to take a look at it with Cachegrind if a test case can be produced. N |