[Interest] Using leveldb in a Qt app redirects unrelated system malloc calls to tcmalloc?

[René J.V. Bertin]

Hi,

A bit of a long shot, but since leveldb is used by QtWebEngine this might ring a bell to someone here:

Below is a bit of backtrace of a Qt application (KDevelop) on Mac in which I've started experimenting with using leveldb. Under certain conditions the entire app freezes, and then I see this in the debugger:

* thread #1: tid = 0x1105e90, 0x00007fff8f75eb16 libsystem_kernel.dylib`syscall_thread_switch + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff8f75eb16 libsystem_kernel.dylib`syscall_thread_switch + 10
    frame #1: 0x00007fff92529df6 libsystem_platform.dylib`_OSSpinLockLockSlow + 63
    frame #2: 0x00007fff8d86890d libsystem_pthread.dylib`_pthread_testcancel + 28
    frame #3: 0x00007fff99864d2e libsystem_c.dylib`nanosleep + 42
    frame #4: 0x000000010b75b7b1 libtcmalloc.4.dylib`base::internal::SpinLockDelay(int volatile*, int, int) + 122
    frame #5: 0x000000010b75b6af libtcmalloc.4.dylib`SpinLock::SlowLock() + 41
    frame #6: 0x000000010b74fe00 libtcmalloc.4.dylib`tcmalloc::CentralCacheLockAll() + 56
    frame #7: 0x00007fff97676cd1 libsystem_malloc.dylib`_malloc_fork_prepare + 49
    frame #8: 0x00007fff997fa161 libsystem_c.dylib`fork + 12
    frame #9: 0x0000000106be1c63 QtCore`forkfd(flags=<unavailable>, ppid=0x00007fff5c5e650c) + 483 at forkfd.c:691
    frame #10: 0x0000000106bd5801 QtCore`QProcessPrivate::startProcess(this=0x0000000129019100) + 3537 at qprocess_unix.cpp:471
    frame #11: 0x0000000106bd180f QtCore`QProcessPrivate::start(this=0x0000000129019100, mode=<unavailable>) + 431 at qprocess.cpp:2177
    frame #12: 0x0000000106bd14ca QtCore`QProcess::start(this=<unavailable>, program=<unavailable>, arguments=0x00000001289e5a28, mode=<unavailable>) + 154 at qprocess.cpp:2089
SNIP

Further frames are completely unrelated to the leveldb code I'm writing. It looks like leveldb makes a process-wide change that causes malloc() to redirect to libtcmalloc. Not that I mind the idea, but it seems clear that tcmalloc isn't "expecting to be called" here, and deadlocks.

Has anyone seen this kind of behaviour before?

Thanks,
R.