debuggingsegmentation-faultpthreadsmallocelectric-fence

electric-fence with pthread


I'm working on a multithreaded (pthread based) project. The project uses a library that I'm writing.

In order to check it I linked it with -lefence and it gave me SIGSEGV. After a lot of time spent in figuring out what's wrong, I finally decided to search the error on the library, even if it's functionality is extremely simple.

As test, I've tried to compile the test-unit linking with -lefence and I got SIGSEGV. The test is not messing with dynamically allocated memory, with the exception of code which, in different test units, succeded.

I noticed also that the -pthread flag sets the memory allocation as wrapped. gcc -dumpspecs | grep pthread produces the following:

%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
%{pthread:-lpthread}    %{shared:-lc}    %{!shared:%{mieee-fp:-lieee} %{profile:-lc_p}%{!profile:-lc}}
 %{static: %{fmudflap|fmudflapth:  --wrap=malloc --wrap=free --wrap=calloc --wrap=realloc --wrap=mmap --wrap=munmap --wrap=alloca} %{fmudflapth: --wrap=pthread_create}} %{fmudflap|fmudflapth: --wrap=main}

Can it be the case that libefence is not supporting multithreading?

Edit: Basically I'm supposing that the electric fence library replaces the malloc/free calls of the regular libc. The fact that they have been wrapped with a thread-safe hood is useless, since they've wrapped again with non-reentrant stuff.


Solution

  • Check put these two - it definitely did have a problem with phthread ( https://bugzilla.redhat.com/show_bug.cgi?id=54368 ) but recently someone claimed a fix ( http://www.mail-archive.com/debian-bugs-closed@lists.debian.org/msg280548.html ) Notice also the mention of another, delayed patch.