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 1848116 - OpenVDB should not be built with concurrent malloc (jemalloc)
Summary: OpenVDB should not be built with concurrent malloc (jemalloc)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: openvdb
Version: epel8
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Simone Caronni
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-06-17 17:24 UTC by Richard Shaw
Modified: 2020-07-08 00:26 UTC (History)
2 users (show)

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:
Clone Of:
Environment:
Last Closed: 2020-07-01 01:36:33 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Richard Shaw 2020-06-17 17:24:30 UTC
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.)
"""

Comment 1 Fedora Update System 2020-06-22 15:20:32 UTC
FEDORA-2020-47497ac2a6 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-47497ac2a6

Comment 2 Fedora Update System 2020-06-22 15:20:39 UTC
FEDORA-EPEL-2020-6c546ada30 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6c546ada30

Comment 3 Fedora Update System 2020-06-22 15:20:45 UTC
FEDORA-2020-8a5ed9e675 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8a5ed9e675

Comment 4 Fedora Update System 2020-06-22 22:15:37 UTC
FEDORA-2020-8a5ed9e675 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8a5ed9e675

Comment 5 Fedora Update System 2020-06-22 22:15:48 UTC
FEDORA-2020-47497ac2a6 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-47497ac2a6

Comment 6 Fedora Update System 2020-06-23 01:05:10 UTC
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.

Comment 7 Fedora Update System 2020-06-23 01:20:15 UTC
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.

Comment 8 Fedora Update System 2020-06-23 01:54:33 UTC
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.

Comment 9 Fedora Update System 2020-07-01 01:36:33 UTC
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.

Comment 10 Fedora Update System 2020-07-01 01:50:18 UTC
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.

Comment 11 Fedora Update System 2020-07-08 00:26:36 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.