|
From: Alfonso A. <alf...@gm...> - 2012-12-12 19:10:09
|
Hi, I am trying to run Valgrind on a Linux program which sets its own hooks for certain libc functions (malloc, calloc and free among them). To that effect, instead of using LD_PRELOAD, and for reasons I believe are not really relevant for the discussion, the first bytes of the code from these function are overwritten with a jump to a hijacking function. It seems that Valgrind doesn't like this kind of run-time modifications since it crashes on the first call to the hijacked calloc whereas the program runs just fine when not involving Valgrind. My guess is that Valgrind associates these symbols with its own hooks at load time and that the subsequent function overwriting breaks Valgrind in certain way. Could you confirm that? Any pointers to how to investigate this further? This hooking mechanism has been tested thoroughly in different architectures. Additionally, the program runs just fine under Valgrind when disabling it. Here is the output when running it under Valgrind (i686/Linux) with hijacking enabled: valgrind ./main ==29484== Memcheck, a memory error detector ==29484== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==29484== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==29484== Command: ./main ==29484== ==29484== Invalid read of size 4 ==29484== at 0x4974D1C: calloc (malloc.c:3260) ==29484== by 0x6BAD6B1: __vf_init_thread (in /home1a/alfonso/vfroot/vfmerge/install/x86_64-linux/vfexec/i686-linux/lib/libvfrun.so.1.0.1) ==29484== by 0x6BADA81: __vf_run_vfs (in /home1a/alfonso/vfroot/vfmerge/install/x86_64-linux/vfexec/i686-linux/lib/libvfrun.so.1.0.1) ==29484== by 0x8048DD1: ??? (in /home1a/alfonso/vfmerge/service-tst/convolution/src/main) ==29484== Address 0x4 is not stack'd, malloc'd or (recently) free'd ==29484== ==29484== ==29484== Process terminating with default action of signal 11 (SIGSEGV) ==29484== Access not within mapped region at address 0x4 ==29484== at 0x4974D1C: calloc (malloc.c:3260) ==29484== by 0x6BAD6B1: __vf_init_thread (in /home1a/alfonso/vfroot/vfmerge/install/x86_64-linux/vfexec/i686-linux/lib/libvfrun.so.1.0.1) ==29484== by 0x6BADA81: __vf_run_vfs (in /home1a/alfonso/vfroot/vfmerge/install/x86_64-linux/vfexec/i686-linux/lib/libvfrun.so.1.0.1) ==29484== by 0x8048DD1: ??? (in /home1a/alfonso/vfmerge/service-tst/convolution/src/main) ==29484== If you believe this happened as a result of a stack ==29484== overflow in your program's main thread (unlikely but ==29484== possible), you can try to increase the size of the ==29484== main thread stack using the --main-stacksize= flag. ==29484== The main thread stack size used in this run was 8388608. ==29484== ==29484== HEAP SUMMARY: ==29484== in use at exit: 40,801 bytes in 403 blocks ==29484== total heap usage: 419 allocs, 16 frees, 43,121 bytes allocated ==29484== ==29484== LEAK SUMMARY: ==29484== definitely lost: 362 bytes in 5 blocks ==29484== indirectly lost: 4,876 bytes in 2 blocks ==29484== possibly lost: 0 bytes in 0 blocks ==29484== still reachable: 35,563 bytes in 396 blocks ==29484== suppressed: 0 bytes in 0 blocks ==29484== Rerun with --leak-check=full to see details of leaked memory ==29484== ==29484== For counts of detected and suppressed errors, rerun with: -v ==29484== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Segmentation fault Thanks, Alfonso Acosta |