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
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to