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

René J.V. Bertin rjvbertin at gmail.com
Thu Apr 12 21:08:09 CEST 2018


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

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?


More information about the Interest mailing list