Crash on Firefox start with mimalloc being ld.so.preload'ed about mimalloc HOT 19 CLOSED

However, I still think that since Firefox links directly with jemalloc things may not work correctly.

That's not engineer's way of thinking. jemalloc isn't a magic

Ummm... not an "engineer's way of thinking" huh ...

Look, Firefox may use internal jemalloc calls, like xallocx and that will not mix well with a dynamically patched free that uses the mimalloc free. To test properly, we need a build that is not linked statically with jemalloc.

If you have other programs that leak memory I am very interested to get some way to reproduce this locally so I can fix mimalloc.

Best, Daan

from mimalloc.

Ah, Firefox is statically compiled with jemalloc and I don't think it behaves well when trying to LD_PRELOAD another allocator. I get the same with tcmalloc:

$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libtcmalloc.so firefox
ExceptionHandler::GenerateDump cloned child 23725
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
Gtk-Message: 00:20:00.284: GtkDialog mapped without a transient parent. This is discouraged.
Segmentation fault (core dumped)

I think it is because a overridden pointer is freed with the builtin jemalloc but not sure. It works with some other allocators, which may either be accidental, or something to do with pthreads?? not sure either

from mimalloc.

tcmalloc used to work just fine being pre-loaded to Firefox. Probably something's changed on FF side. Typically if everything's done correctly nesting mem. allocators should be seamless.

from mimalloc.

Meanwhile, 1.0.3 doesn't show that behaviour.

from mimalloc.

git bisected to 49ceb4 where it's become broken again

nope, my bad — broken since 461b8ae which follows 49ceb4. 49ceb4 isn't guilty…

from mimalloc.

Ha, that is so strange! I still think that due to Firefox being linked directy with jemalloc strange thing might be going on (also given that tcmalloc crashes with it too).
However, it seems v1.0.3 up to, but not including 49ceb4d works?
But 49ceb4d doesn't seem to have done anything except move some code around...

from mimalloc.

1.0.0 — crash
1.0.2 works as well as 1.0.3 does

from mimalloc.

I've bisected v1.0.0 to v1.0.2 and it works since c352820.

from mimalloc.

Interesting -- I wonder if it is due to the overriding of C++ operators

from mimalloc.

I've re-done bisecting 1.0.3 to 1.0.4: crashes on 461b8ae

from mimalloc.

I bet it is the overloading of C++ operators. Looking at that patch, assuming we build mimalloc normally using the C compiler on 64-bit, it may be that:

1. Adding:

   void* _Znwmm(uint64_t n, uint64_t align) { return mi_malloc_aligned(n,align); } // aligned new 64-bit
   void* _Znamm(uint64_t n, uint64_t align) { return mi_malloc_aligned(n,align); } // aligned new[] 64-bit

   back in again may fix it.

2. Or, removing:
   void* _ZnwmRKSt9nothrow_t(size_t n, mi_nothrow_t tag) { UNUSED(tag); return mi_new_nothrow(n); }
   void* _ZnamRKSt9nothrow_t(size_t n, mi_nothrow_t tag) { UNUSED(tag); return mi_new_nothrow(n); }
   void* _ZnwmSt11align_val_tRKSt9nothrow_t(size_t n, size_t al, mi_nothrow_t tag) { UNUSED(tag); return mi_new_aligned_nothrow(n,al); }
   void* _ZnamSt11align_val_tRKSt9nothrow_t(size_t n, size_t al, mi_nothrow_t tag) { UNUSED(tag); return mi_new_aligned_nothrow(n,al); }

from mimalloc.

nope

from mimalloc.

Program terminated with signal SIGSEGV, Segmentation fault.
#0  __GI___pthread_mutex_lock (mutex=0x18) at ../nptl/pthread_mutex_lock.c:65
65  ../nptl/pthread_mutex_lock.c: No such file or directory.
(gdb) bt
#0  __GI___pthread_mutex_lock (mutex=0x18) at ../nptl/pthread_mutex_lock.c:65
#1  0x0000557d93cdb4ab in free ()
#2  0x00007f9d379c4201 in ?? () from /usr/lib/firefox/libxul.so
#3  0x00007f9d379c5f4b in ?? () from /usr/lib/firefox/libxul.so

— std::get_new_handler is thread-safe, what about code that tinkers with new-handler while compiled in C mode?

from mimalloc.

I've bisected v1.0.0 to v1.0.2 and it works since c352820.

Narrowed it down to c352820#diff-03a18af4e96d9738f2da8285463054bdR119

where code gets commented out with #if 0. Uncommenting it with #if 1 reverts to crashing.

from mimalloc.

In e946d56 there's no trouble with Firefox run.
Buuut looking at some long-runners I'd say there's a mem. leak.

from mimalloc.

Ah great to hear it seems at least to work. However, I still think that since Firefox links directly with jemalloc things may not work correctly. From others, I have heard that it can work if you build Firefox yourself with jemalloc disabled in the build flags -- the LD_PRELOAD should be working.

So, a mem leak might be by mimalloc, or not... also, it might also be due to fragmentation where there is no leak perse, but memory usage increases due to fragmented pages (which is still bad and should be addressed in mimalloc if that is the case -- you can generally spot the difference as a leak is a linear increase while fragmentation tends to taper off over time).

I will take a look as it is my goal to use Firefox as a benchmark but I think we should at least start with a jemalloc disabled build.

(also, inside Microsoft mimalloc is now used on some very large services with huge workloads and there are no leaks/fragmentation even over long runs. (of course that doesn't mean there could still not be a bug somewhere but it does inspire confidence :-) ))

from mimalloc.

However, I still think that since Firefox links directly with jemalloc things may not work correctly.

That's not engineer's way of thinking. jemalloc isn't a magic (although some people would tell it does some magic in regards of memory saving). :)

Those times when I tried git-bisecting (logged here before — look it up above) it was pretty much related to tinkering with C++ intrinsics.

from mimalloc.

As to mem. leaks — I didn't say it was noticed with Firefox. In fact it was some other software. And yeah, its RAM usage grows too fast to be explained with anything else except mimalloc's bug.

from mimalloc.

(also, inside Microsoft mimalloc is now used on some very large services with huge workloads and there are no leaks/fragmentation even over long runs. (of course that doesn't mean there could still not be a bug somewhere but it does inspire confidence :-) ))

Sure, sounds great. I've told you that it happens with e946d56 — is it same as that revision that's been heavily tested inside Microsoft?

from mimalloc.