|
From: Mathieu L. <mat...@gm...> - 2009-07-31 11:44:55
|
hi, I am trying to debug an application failing with an elf loader of mine. Unsurprisingly, my code is buggy which leads to: ==7799== Conditional jump or move depends on uninitialised value(s) ==7799== at 0x3F5D87F42D: (within /lib64/libc-2.10.1.so) ==7799== by 0x3F5EC13133: (within /lib64/libselinux.so.1) ==7799== by 0x4020E87: ??? ==7799== by 0x3F5D88892B: (within /lib64/libc-2.10.1.so) ==7799== by 0x421224F: ??? ==7799== by 0x77: ??? ==7799== by 0x401116F: ??? ==7799== by 0x3F5EE1BD5F: (within /lib64/libselinux.so.1) ==7799== by 0x7FEFFFF77: ??? ==7903== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y ==7903== starting debugger with cmd: /usr/bin/gdb -nw /proc/7904/fd/1014 7904 GNU gdb (GDB) Fedora (6.8.50.20090302-33.fc11) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Attaching to program: /proc/7904/fd/1014, process 7904 [loading symbols] strlen () at ../sysdeps/x86_64/strlen.S:40 40 jnz 1f (gdb) bt #0 strlen () at ../sysdeps/x86_64/strlen.S:40 #1 0x0000003f5ec13134 in init_selinux_config () at selinux_config.c:166 #2 0x0000003f5ec15516 in __do_global_ctors_aux () from /lib64/libselinux.so.1 #3 0x0000003f5ec04c9b in _init () from /lib64/libselinux.so.1 #4 0x00000007ff000018 in ?? () #5 0x000000000400a3fe in call_init (file=0x4019cb0) at vdl-init-fini.c:88 #6 0x000000000400a4a3 in vdl_init_fini_call_init (files=0x4021af0) at vdl-init-fini.c:111 #7 0x000000000400bb56 in stage2_initialize (input= {interpreter_load_base = 67108864, program_phdr = 0x400040, program_phnum = 8, sysinfo = 0, program_argc = 1, program_argv = 0x7ff0002b8, program_envp = 0x7ff0002c8}) at stage2.c:327 #8 0x000000000400b059 in stage1 (input_output=0x7ff000290) at stage1.c:192 #9 0x000000000400bc8a in L1 () from ./ldso #10 0x0000000000000000 in ?? () Current language: auto; currently asm (gdb) p $rip $1 = (void (*)()) 0x3f5d87f42d <strlen+45> (gdb) disas Dump of assembler code for function strlen: 0x0000003f5d87f400 <strlen+0>: mov %rdi,%rcx 0x0000003f5d87f403 <strlen+3>: mov %rdi,%r8 0x0000003f5d87f406 <strlen+6>: and $0xfffffffffffffff0,%rdi 0x0000003f5d87f40a <strlen+10>: pxor %xmm1,%xmm1 0x0000003f5d87f40e <strlen+14>: or $0xffffffffffffffff,%esi 0x0000003f5d87f411 <strlen+17>: movdqa (%rdi),%xmm0 0x0000003f5d87f415 <strlen+21>: sub %rdi,%rcx 0x0000003f5d87f418 <strlen+24>: lea 0x10(%rdi),%rdi 0x0000003f5d87f41c <strlen+28>: pcmpeqb %xmm1,%xmm0 0x0000003f5d87f420 <strlen+32>: shl %cl,%esi 0x0000003f5d87f422 <strlen+34>: pmovmskb %xmm0,%edx 0x0000003f5d87f426 <strlen+38>: xor %eax,%eax 0x0000003f5d87f428 <strlen+40>: neg %r8 0x0000003f5d87f42b <strlen+43>: and %esi,%edx 0x0000003f5d87f42d <strlen+45>: jne 0x3f5d87f443 <strlen+67> 0x0000003f5d87f42f <strlen+47>: movdqa (%rdi),%xmm0 0x0000003f5d87f433 <strlen+51>: lea 0x10(%rdi),%rdi 0x0000003f5d87f437 <strlen+55>: pcmpeqb %xmm1,%xmm0 0x0000003f5d87f43b <strlen+59>: pmovmskb %xmm0,%edx 0x0000003f5d87f43f <strlen+63>: test %edx,%edx 0x0000003f5d87f441 <strlen+65>: je 0x3f5d87f42f <strlen+47> 0x0000003f5d87f443 <strlen+67>: lea -0x10(%rdi,%r8,1),%rdi 0x0000003f5d87f448 <strlen+72>: bsf %edx,%eax 0x0000003f5d87f44b <strlen+75>: add %rdi,%rax 0x0000003f5d87f44e <strlen+78>: retq ---Type <return> to continue, or q <return> to quit---q Quit (gdb) The above looks like a jne instruction depending on unitialized value in strlen called from init_selinux_config. It's not clear to me how it could possibly depend on uninitialized data (maybe one of the 2 registers in "and %esi,%edx" is not initialized properly) but, well. What I am really curious about is why the backtrace output by valgrind does not show the symbolic names of my functions. Would someone mind point me to the code in valgrind which performs symbol lookups so that I can figure out what I need to do in my loader to make at least this work ? Mathieu -- Mathieu Lacage <mat...@gm...> |
|
From: Nicholas N. <n.n...@gm...> - 2009-07-31 21:51:16
|
On Fri, Jul 31, 2009 at 9:44 PM, Mathieu Lacage<mat...@gm...> wrote: > > What I am really curious about is why the backtrace output by valgrind > does not show the symbolic names of my functions. Would someone mind > point me to the code in valgrind which performs symbol lookups so that > I can figure out what I need to do in my loader to make at least this > work ? It's in coregrind/m_debuginfo/. The FAQ also has a question relating to stack traces that you might find helpful. Nick |
|
From: Mathieu L. <mat...@gm...> - 2009-08-31 14:20:34
|
hi, On Fri, Jul 31, 2009 at 11:51 PM, Nicholas Nethercote<n.n...@gm...> wrote: >> What I am really curious about is why the backtrace output by valgrind >> does not show the symbolic names of my functions. Would someone mind >> point me to the code in valgrind which performs symbol lookups so that >> I can figure out what I need to do in my loader to make at least this >> work ? > > It's in coregrind/m_debuginfo/. The FAQ also has a question relating > to stack traces that you might find helpful. Just in case anyone ever stumbles upon similar problems, I tracked this down as coming from valgrind's di_notify_unmap which is overly aggressive in removing debug object descriptors from its global list. I re-arranged my code to produce the same memory mappings but with the mmap & munmap in a different order and its worked. i.e., when I do an munmap of a memory area backed by a debug object descriptor, this triggers its deletion, even when the munmap is really removing only a small part of the object memory mapping which is unused. I merely moved all munmaps to _before_ the mmaps to make sure that all debug object descriptors are created with the right memory mapping size from the start... It was fun to debug :) Mathieu -- Mathieu Lacage <mat...@gm...> |