Description of problem: This works with glibc posix_memalign. When linking tcmalloc to override the weak posix_memalign symbol, in some conditions (generally during a stress test) the following segmentation fault is experienced. I can reproduce this 100% of the time. This may be due to an incorrect check in the freelist under high memalign/free pressure. Thread 22 "lt-benchmark_pa" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff3429700 (LWP 15025)] tcmalloc::SLL_Pop (list=0x6fda48) at src/linked_list.h:59 59 *list = SLL_Next(*list); (gdb) bt #0 tcmalloc::SLL_Pop (list=0x6fda48) at src/linked_list.h:59 #1 tcmalloc::ThreadCache::FreeList::Pop (this=<optimized out>) at src/thread_cache.h:212 #2 tcmalloc::ThreadCache::Allocate (cl=<optimized out>, size=<optimized out>, this=<optimized out>) at src/thread_cache.h:371 #3 (anonymous namespace)::do_memalign (align=align@entry=64, size=<optimized out>, size@entry=80) at src/tcmalloc.cc:1462 #4 0x00007ffff7778669 in (anonymous namespace)::do_memalign_or_cpp_memalign (size=80, align=64) at src/tcmalloc.cc:1131 #5 tc_posix_memalign (result_ptr=result_ptr@entry=0x7ffff3428be0, align=align@entry=64, size=size@entry=80) at src/tcmalloc.cc:1781 #6 0x00007ffff79baa8f in sds_memalign (size=size@entry=80, alignment=alignment@entry=64) at /home/william/development/389ds/ds/src/libsds/sds/core/utils.c:110 #7 0x00007ffff79bfd20 in sds_bptree_txn_create (binst=binst@entry=0xe3c100) at /home/william/development/389ds/ds/src/libsds/sds/bpt_cow/txn.c:31 #8 0x00007ffff79bfecd in sds_bptree_cow_wrtxn_begin (binst=0xe3c100, btxn=0x7ffff3428c78) at /home/william/development/389ds/ds/src/libsds/sds/bpt_cow/txn.c:292 #9 0x00000000004022c4 in bptree_cow_write_begin (inst=<optimized out>, write_txn=<optimized out>) at /home/william/development/389ds/ds/src/libsds/test/benchmark_parwrap.c:141 #10 0x0000000000402865 in batch_insert (info=0x7fffffffe1c0) at /home/william/development/389ds/ds/src/libsds/test/benchmark_par.c:181 #11 0x0000000000402e3b in bench_thread_batch (arg=0x7fffffffe1c0) at /home/william/development/389ds/ds/src/libsds/test/benchmark_par.c:232 #12 0x00007ffff7122e8b in _pt_root (arg=0xe3e240) at ../../../nspr/pr/src/pthreads/ptthread.c:216 #13 0x00007ffff66e136d in start_thread (arg=0x7ffff3429700) at pthread_create.c:456 #14 0x00007ffff6c235bf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
This backtrace seems to come from gperftools 2.5 (Fedora), not RHEL.
(In reply to wibrown from comment #0) > Description of problem: > > This works with glibc posix_memalign. When linking tcmalloc to override the > weak posix_memalign symbol, in some conditions (generally during a stress > test) the following segmentation fault is experienced. I can reproduce this > 100% of the time. This may be due to an incorrect check in the freelist > under high memalign/free pressure. Do you have a small, obviously correct test case which exposes this problem? The stronger barrier in the glibc malloc could hide an concurrency bug in the application, so this is not necessarily a tcmalloc issue.
Possibly (remotely?) related to bz1494309 ?
Closing bug, 389-ds-base is no longer going to use tcmalloc because gperftools is going away.
gperftools is going away? Upstream is still making releases, perhaps you mean "will not be in future RHEL builds"?
(In reply to Tom "spot" Callaway from comment #6) > gperftools is going away? Upstream is still making releases, perhaps you > mean "will not be in future RHEL builds"? My understanding is that it "is" going away. The glibc team is no longer maintaining it (or is going to stop maintaining it very soon), and we've all been told to stop using it: https://bugzilla.redhat.com/show_bug.cgi?id=1496871 https://bugzilla.redhat.com/show_bug.cgi?id=1496872 These are RHEL bugs, but if no one is maintaining it and no one is supporting it, then it's dead IMO. I could be wrong, this is just my understanding of the situation. Anyway in 389-ds-base we plan to bundle jemalloc starting in F28.
There were commits upstream 10 days ago: https://github.com/gperftools/gperftools/commits/master and an RC release in March: https://github.com/gperftools/gperftools/releases I was not under the impression that glibc was _ever_ the maintainer for this.
Replying to myself, but it appears that the request is to use the new per-thread local cache implementation within glibc, instead of using tcmalloc. This is different from "gperftools" is dead/going away.
I apologize for the bad terminology. I misunderstood what was really happening. It looks like the only reason behind all of this was that gperftools was being dropped from RHEL.
(In reply to mreynolds from comment #7) > (In reply to Tom "spot" Callaway from comment #6) > > gperftools is going away? Upstream is still making releases, perhaps you > > mean "will not be in future RHEL builds"? > > My understanding is that it "is" going away. The glibc team is no longer > maintaining it (or is going to stop maintaining it very soon), and we've all > been told to stop using it: The glibc team does not maintain the alternative allocators, and never has. We simply do not have expertise in this area. > https://bugzilla.redhat.com/show_bug.cgi?id=1496871 > https://bugzilla.redhat.com/show_bug.cgi?id=1496872 > > These are RHEL bugs, but if no one is maintaining it and no one is > supporting it, then it's dead IMO. For Fedora, we are fine as long as there is an active upstream. I'm not sure if we have expertise in Fedora to diagnose and fix issues in tcmalloc, but even if the expertise is missing, we can still ship it as a leaf package in case someone wants to self-support, or use it for upstream projects where it is the default. The challenge for Fedora is our selection of architectures, and some upstream projects might unconditionally enable allocators for all architectures, but have only tested their usage on common ones such as x86-64.