3

In order to diagnose a tricky memory corruption bug (memory is getting randomly overwritten) I thought about utilizing Electric Fence + some custom mprotect calls to ensure that the corrupted data structures are only writable when I want them to be written to (and I immediately get a SIGSEGV when they are attempted to be written to).

Unfortunately, said code is a Ruby C Extension, which makes running it under libefence a performance nightmare as running the whole ruby interpreter under libefence using

export LD_PRELOAD=libefence.so.0.0

is horribly slow.

OTOH, linking the ruby extension with libefence directly (by passing -lefence to the linker) seems to have no effect causing it to run without libefence's instrumentation.

Is there a way to run only the memory allocations happening in a specific shared library through libefence and leaving other shared libs and the main process alone?

DavidH
  • 415
  • 4
  • 21
Thilo-Alexander Ginkel
  • 6,898
  • 10
  • 45
  • 58

1 Answers1

1

The simplest way would be to link the Ruby C extension with a static libefence library. There could still be problems though - what if something is malloc()ed in your extension but freed within ruby?

If you get a SIGSEGV straight away but want speed - you may want to use gdb. As soon as the SIGSEGV occurs the debugger will break.

Alternatively valgrind is good for finding memory problems but is also slow.

teambob
  • 1,994
  • 14
  • 19
  • Thanks for your suggestion. Unfortunately, static linking does not seem to work due to some incompatibilities: /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.4.5/crtbeginT.o: relocation R_X86_64_32 against `__DTOR_END__' can not be used when making a shared object; recompile with -fPIC I also tried valgrind before going the efence route, which is acceptable performance-wise, but cannot pin-point the specific bug I am hunting (corruption of valid pages). – Thilo-Alexander Ginkel Oct 13 '10 at 23:41
  • (cont'd): I'll try putting together some custom page-oriented memory allocation tomorrow (doing mallocs on page granularity is important as I can't use mprotect otherwise). – Thilo-Alexander Ginkel Oct 13 '10 at 23:44
  • Could you state at a higher level the problem you are trying to solve? – teambob Oct 14 '10 at 03:04