Bug 1430223
| Summary: | In some conditions, tcmalloc memalign will segfault | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | wibrown <wibrown> |
| Component: | gperftools | Assignee: | Tom "spot" Callaway <tcallawa> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 26 | CC: | bhubbard, databases-maint, fweimer, herrold, mreynolds, pbonzini, tcallawa, vashirov |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-04-20 22:12:19 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
wibrown@redhat.com
2017-03-08 04:39:22 UTC
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. 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. |