Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1109309
Summary: | gperftools self-deadlock on ARM | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jerry James <loganjerry> |
Component: | gperftools | Assignee: | Tom "spot" Callaway <tcallawa> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 22 | CC: | loganjerry, pbrobinson, tcallawa |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | armhfp | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-07-19 19:02:12 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: | |||
Bug Depends On: | |||
Bug Blocks: | 245418 |
Description
Jerry James
2014-06-13 15:42:36 UTC
After staring at that backtrace for a bit, I think I see what happened. The gperftools code wants to record the construction of the page heap (frame 27), so it calls into a backend-specific stack trace generator (frame 23), which happens to be libunwind in this case. The libunwind code then walks the stack to gather its information. It decides it really needs to look at /lib/libprofiler.so.0 and so calls fopen (frame 11) ... and fopen now calls malloc() (frame 10). So the bug here is that while the malloc() infrastructure is still setting itself up, it makes a call into libunwind that makes a call into glibc that calls malloc(). This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22 (In reply to Jerry James from comment #1) > After staring at that backtrace for a bit, I think I see what happened. The > gperftools code wants to record the construction of the page heap (frame > 27), so it calls into a backend-specific stack trace generator (frame 23), > which happens to be libunwind in this case. The libunwind code then walks > the stack to gather its information. It decides it really needs to look at > /lib/libprofiler.so.0 and so calls fopen (frame 11) ... and fopen now calls > malloc() (frame 10). > > So the bug here is that while the malloc() infrastructure is still setting > itself up, it makes a call into libunwind that makes a call into glibc that > calls malloc(). cvc4 appears to be built in F-22 so is this still a problem with gperftools 2.4 on ARMv7? Since cvc4 can be built either with or without gperftools, I chose to build without in order to avoid this bug. I can try building with again at any time to see if the bug is still present. A scratch build with it enabled built but it looks like the support for it was disabled over all for other reasons http://koji.fedoraproject.org/koji/taskinfo?taskID=9536750 That scratch build did not include gperftools support. The build log says: checking whether to link in google perftools libraries... no (user didn't request it) You'll need to add --with-google-perftools to the %configure line. I disabled it all over both because of this bug, and because something is broken on i386. I was getting wrong answers out of cvc4 on i386. I tried running under valgrind to see if we had some kind of memory corruption going on, and sure enough, valgrind reported a large number of memory errors, all with backtraces that involved gperftools functions. Just for kicks, I tried building without gperftools support ... and the memory errors and wrong answers all went away. Now valgrind doesn't report any problems, and cvc4 gives correct answers. So either gperftools is broken (in a different way) on i386, or cvc4 is using gperftools incorrectly somehow. In any case, I decided to build cvc4 without gperftools support to avoid the arm and i386 problems. Perhaps strangely, cvc4 + gperftools seems to work just fine on x86_64. Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |