#395 segmentation fault during init with statically linked jemalloc on i686

[Daniel Micay]

Here's a simple program using jemalloc (not using the include file for simplicity):

#include <stddef.h>

extern void *je_malloc(size_t size);
extern void je_free(void *ptr);

int main() {
    void *ptr = je_malloc(32);
    je_free(ptr);
    return 0;
}

Get jemalloc and build it:

git clone "https://github.com/jemalloc/jemalloc.git"
cd jemalloc
# check out a recent stable tag if you want, it doesn't matter
./configure --with-jemalloc-prefix=je_ --with-private-namespace=je_
make build_lib_static

Now just link the simple C code against the libraries in the lib/ directory. If you use the dynamic library (jemalloc.dll) it works fine, but using the static library (jemalloc_s.lib) hits a segmentation fault. This worked fine with an old version of mingw. I've only confirmed that this exists on i686 at the moment.

Program received signal SIGSEGV, Segmentation fault.
0x77eaf0a3 in ntdll!RtlSetUserValueHeap () from C:\Windows\SYSTEM32\ntdll.dll

Sadly, gdb fails to produce a backtrace with more context.

[Ozkan Sezer]

Possibly this: ???
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888

(This is a very wild guess though, and it may be totally unrelated.)

[Daniel Micay]

The segmentation fault occurs even if the jemalloc code is never called:

#include <stddef.h>

extern void *je_malloc(size_t size);
extern void je_free(void *ptr);

int foo() {
        je_free(0);
}

int main(int argc, char **argv) {
    if (argc == -1) {
        foo();
    }
    return 0;
}

I'm not sure if jemalloc is sneaking in any hidden initialization code though...

I don't think this can be a bug in the compiler because jemalloc is using the same object files for both the static and dynamic library, but it's only broken with the static library. It seems like it must be a linker bug of some sort.

[Daniel Micay]

Using --enable-lazy-lock with jemalloc works. Passing this disables the lock initialization code (before main runs) and runs it on the first pthread_create call instead. The code does run fine when spawning a thread, so it appears to be an initialization problem related to threading. I'm still convinced this is a mingw-w64 bug rather than a jemalloc bug.