Bug 1848116
Summary: | OpenVDB should not be built with concurrent malloc (jemalloc) | ||
---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | Richard Shaw <hobbes1069> |
Component: | openvdb | Assignee: | Simone Caronni <negativo17> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | epel8 | CC: | luya_tfz, negativo17 |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | openvdb-7.0.0-7.fc31 openvdb-7.0.0-7.fc32 openvdb-7.0.0-7.el8 | Doc Type: | --- |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-07-01 01:36:33 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: |
FEDORA-2020-47497ac2a6 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-47497ac2a6 FEDORA-EPEL-2020-6c546ada30 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6c546ada30 FEDORA-2020-8a5ed9e675 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8a5ed9e675 FEDORA-2020-8a5ed9e675 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8a5ed9e675 FEDORA-2020-47497ac2a6 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-47497ac2a6 FEDORA-2020-8a5ed9e675 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-8a5ed9e675` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8a5ed9e675 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-EPEL-2020-6c546ada30 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6c546ada30 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-47497ac2a6 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-47497ac2a6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-47497ac2a6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-47497ac2a6 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2020-8a5ed9e675 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-EPEL-2020-6c546ada30 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report. |
Description of problem: Current build prevents OpenImageIO python module from functioning. Version-Release number of selected component (if applicable): openvdb-7.0.0-3.el8 How reproducible: Every time Steps to Reproduce: 1. Attempt to import OIIO python module. Actual results: >>> import OpenImageIO \Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: /lib64/libjemalloc.so.2: cannot allocate memory in static TLS block Expected results: Module imports properly Additional info: OIIO upstream comment: """ The best solution is to make sure your OpenVDB is built with -DCONCURRENT_MALLOC=None. I believe it is just wrong to build a library that forces a process-wide malloc substitute, as it will inadvertently pollute any applications or other libraries it's linked into. Like, in this case, Python, which seems like a bad idea. Only *applications* (final link, not a single library), should specify a wholesale malloc replacement, it should be up to them whether it's appropriate. This is not a knock on jemalloc per se -- which is great. In fact, we use it in our renderer without trouble and have never seen this problem. (Also: we just did a painful pass through our studio's code base trying to root out places where libraries were pulling in jemalloc and other alternate mallocs in behind the back of applications, and mainly it required a new build of OpenVDB with this option set correctly and then relinking all libraries and apps referencing OpenVDB to switch to the new version.) """