Control: reassign -1 eatmydata
Control: affects -1 mongodb-server-core
Control: retitle -1 eatmydata is incompatible with tcmalloc
Hi,
On 09:24 Thu 06 Sep , Michael Stapelberg wrote:
> This is not a bug with this package, but with mongodb-server:
>
> root@gce1535991:~# mongod --version
> db version v3.4.15
> git version: 52e5b5fbaa3a2a5b1a217f5e647b5061817475f9
> OpenSSL version: OpenSSL 1.1.0f 25 May 2017
> allocator: tcmalloc
> modules: none
> build environment:
> distarch: x86_64
> target_arch: x86_64
> root@gce1535991:~# eatmydata mongod --version
> ^C
It looks like this is an incompatibility between eatmydata and tcmalloc:
(gdb) bt
#0 0x00007f4e24cf9c41 in __GI___nanosleep (requested_time=0x7ffcaa6523e0,
remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
#1 0x00007f4e25d08753 in base::internal::SpinLockDelay(int volatile*, int, int)
() from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4
#2 0x00007f4e25d08623 in SpinLock::SlowLock() ()
from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4
#3 0x00007f4e25cfcf54 in tcmalloc::ThreadCache::InitModule() ()
from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4
#4 0x00007f4e25cfd06d in tcmalloc::ThreadCache::CreateCacheIfNecessary() ()
from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4
#5 0x00007f4e25d0b20a in tc_calloc ()
from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4
#6 0x00007f4e2503ba25 in _dlerror_run (
operate=operate@entry=0x7f4e2503b3b0 <dlsym_doit>,
args=args@entry=0x7ffcaa652500) at dlerror.c:140
#7 0x00007f4e2503b42f in __dlsym (handle=handle@entry=0xffffffffffffffff,
name=name@entry=0x7f4e26144000 "open") at dlsym.c:70
#8 0x00007f4e261430b1 in eatmydata_init () at libeatmydata/libeatmydata.c:80
#9 0x00007f4e261434a5 in eatmydata_is_hungry () at
libeatmydata/libeatmydata.c:96
#10 msync (addr=<optimized out>, length=<optimized out>, flags=<optimized out>)
at libeatmydata/libeatmydata.c:204
#11 0x00007f4e24911fc4 in ?? () from /usr/lib/x86_64-linux-gnu/libunwind.so.8
#12 0x00007f4e24915d21 in ?? () from /usr/lib/x86_64-linux-gnu/libunwind.so.8
#13 0x00007f4e2491601f in ?? () from /usr/lib/x86_64-linux-gnu/libunwind.so.8
#14 0x00007f4e24916569 in ?? () from /usr/lib/x86_64-linux-gnu/libunwind.so.8
#15 0x00007f4e24912ac1 in _ULx86_64_step ()
from /usr/lib/x86_64-linux-gnu/libunwind.so.8
#16 0x00007f4e25d0905b in ?? () from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4
#17 0x00007f4e25d09634 in GetStackTrace(void**, int, int) ()
from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4
#18 0x00007f4e25cfa6a6 in tcmalloc::PageHeap::GrowHeap(unsigned long) ()
from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4
#19 0x00007f4e25cfa93b in tcmalloc::PageHeap::New(unsigned long) ()
from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4
#20 0x00007f4e25cf8865 in tcmalloc::CentralFreeList::Populate() ()
from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4
#21 0x00007f4e25cf8a68 in tcmalloc::CentralFreeList::FetchFromOneSpansSafe(int,
void**, void**) () from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4
#22 0x00007f4e25cf8b67 in tcmalloc::CentralFreeList::RemoveRange(void**,
void**, int) () from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4
#23 0x00007f4e25cfc3a0 in tcmalloc::ThreadCache::FetchFromCentralCache(unsigned
int, int, void* (*)(unsigned long)) ()
from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4
#24 0x00007f4e25d0c775 in tcmalloc::allocate_full_malloc_oom(unsigned long) ()
from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4
#25 0x00007f4e24f46416 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#26 0x00007f4e261af0ca in call_init (l=<optimized out>, argc=argc@entry=2,
argv=argv@entry=0x7ffcaa6535e8, env=env@entry=0x7ffcaa653600) at
dl-init.c:72
#27 0x00007f4e261af1d6 in call_init (env=0x7ffcaa653600, argv=0x7ffcaa6535e8,
argc=2, l=<optimized out>) at dl-init.c:118
#28 _dl_init (main_map=0x7f4e261c9170, argc=2, argv=0x7ffcaa6535e8,
env=0x7ffcaa653600) at dl-init.c:119
#29 0x00007f4e261a124a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
Without digging too deep, AFAICT eatmydata is injected in tcmalloc's
initialization path (#24) through msync (#10), which in turn tries to
calloc() more memory, causing a deadlock. I'm reassigning this to
eatmydata, since I guess it should be as transparent as possible and not
interfere with the underlying memory allocator used.
Regards,
Apollon
