RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1640391 - Binaries compiled against gperftools-libs 2.6 libtcmalloc fail on systems with 2.4 installed
Summary: Binaries compiled against gperftools-libs 2.6 libtcmalloc fail on systems wit...
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gperftools
Version: 7.5
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Paolo Bonzini
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-10-18 00:29 UTC by Brad Hubbard
Modified: 2019-03-08 15:00 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-08 15:00:13 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Ceph Project Bug Tracker 36508 0 None None None 2018-10-18 00:45:40 UTC

Description Brad Hubbard 2018-10-18 00:29:35 UTC
Description of problem:

Binaries compiled against the 2.6 version of the libraries (in this case ceph-osd) have the following undefined symbols.

# nm -D /usr/bin/ceph-osd|egrep '(_ZdaPvm|_ZdlPvm)'                                                                                                                                                                 
                 U _ZdaPvm                                                                                                                                                                                                                  
                 U _ZdlPvm

The 2.4 version of libtcmalloc.so.4 (gperftools-libs-2.4-8.el7.x86_64) does not export these symbols.

# nm -D /usr/lib64/libtcmalloc.so.4|egrep '(_ZdaPvm|_ZdlPvm)'
#

This leads to errors such as the following.

ceph-osd: symbol lookup error: ceph-osd: undefined symbol: _ZdaPvm

Installing gperftools-libs-2.6.1-1.el7.x86_64.rpm resolves the issue.

# nm -D /usr/lib64/libtcmalloc.so.4|egrep '(_ZdaPvm|_ZdlPvm)'
0000000000035dc0 T _ZdaPvm
0000000000035dc0 T _ZdlPvm

Maybe the library version number should have been incremented between these releases?

Comment 1 Brad Hubbard 2018-10-18 00:35:31 UTC
See https://github.com/gperftools/gperftools/commit/7efb3ecf37d88edf9cf9a43efb89b425eaf81d5e , search for "ENABLE_SIZED_DELETE".

Comment 4 Paolo Bonzini 2018-12-14 14:53:33 UTC
> Maybe the library version number should have been incremented between these releases?

The library version number only says that there is no compatibilty between a binary for an old version of the library, on a system with a new version of the library.

Here you have a binary for a new version of the library, on a system with an old version of the library.  It is expected that it fails if the library defines new symbols, and the patch is pretty intrusive so I'd rather avoid this.

What system with 2.6 gperftools did you build on? (Fedora?)

Comment 5 Brad Hubbard 2018-12-14 21:53:08 UTC
(In reply to Paolo Bonzini from comment #4)
> 
> What system with 2.6 gperftools did you build on? (Fedora?)

Centos 7
gperftools.x86_64                                    2.6.1-1.el7                                    base

Comment 6 Paolo Bonzini 2019-03-08 15:00:13 UTC
You need to install the older version if you want to be backwards compatible.


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