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 1729402 - libTsan coming from gcc-toolset-9 leaked through the compose process to RHEL-8.1 BaseOS compose
Summary: libTsan coming from gcc-toolset-9 leaked through the compose process to RHEL-...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: gcc
Version: 8.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.1
Assignee: Marek Polacek
QA Contact: Martin Cermak
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-12 08:03 UTC by Martin Cermak
Modified: 2023-07-18 14:19 UTC (History)
8 users (show)

Fixed In Version: gcc-toolset-9-gcc-9.1.1-2.4.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-05 21:14:11 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:3440 0 None None None 2019-11-05 21:14:19 UTC

Description Martin Cermak 2019-07-12 08:03:43 UTC 
libTsan coming from gcc-toolset-9 leaked through the compose process to RHEL-8.1 BaseOS, where it is effectively replacing the version of libtsan coming from base rhel GCC.  The gcc-toolset based libtsan should only be present in RHEL-8.1 AppStream.  This might only be achieved by renaming gcc-toolset based libtsan.
Comment 1 Martin Cermak 2019-07-12 08:57:40 UTC 
Related: bz1722892.
Comment 2 Marek Polacek 2019-09-23 20:54:05 UTC 
Sorry, I didn't notice this until now.

We can't rename libtsan from GTS 9 because the SONAMEs are the same:
$ rpm -qpl libtsan-8.3.1-4.5.el8.x86_64.rpm
/usr/lib64/libtsan.so.0
/usr/lib64/libtsan.so.0.0.0
$ rpm -qpl libtsan-9.1.1-2.3.el8.x86_64.rpm
/usr/lib64/libtsan.so.0
/usr/lib64/libtsan.so.0.0.0

and we would get conflicts when trying to install libtsan from GTS 9 when the system libtsan was already installed (as in Bug 1722892).

So we need to drop libtsan and liblsan from GTS 9.  Checking if there are any ABI/ABI changes I see:

$ abipkgdiff libtsan-8.3.1-4.5.el8.x86_64.rpm libtsan-9.1.1-2.3.el8.x86_64.rpm
================ changes of 'libtsan.so.0.0.0'===============
  Functions changes summary: 0 Removed, 0 Changed, 0 Added function
  Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
  Function symbols changes summary: 1 Removed, 61 Added function symbols not referenced by debug info
  Variable symbols changes summary: 0 Removed, 0 Added variable symbol not referenced by debug info

  1 Removed function symbol not referenced by debug info:

    _ZN11__sanitizer11CheckFailedEPKciS1_yy

  61 Added function symbols not referenced by debug info:

    _ZdaPvSt11align_val_t
    _ZdaPvSt11align_val_tRKSt9nothrow_t
    _ZdaPvm
    _ZdaPvmSt11align_val_t
    _ZdlPvSt11align_val_t
    _ZdlPvSt11align_val_tRKSt9nothrow_t
    _ZdlPvm
    _ZdlPvmSt11align_val_t
    _ZnamSt11align_val_t
    _ZnamSt11align_val_tRKSt9nothrow_t
    _ZnwmSt11align_val_t
    _ZnwmSt11align_val_tRKSt9nothrow_t
    __fprintf_chk
    __interceptor___fprintf_chk, aliases __fprintf_chk
    __interceptor___pthread_mutex_lock, aliases __pthread_mutex_lock
    __interceptor___pthread_mutex_unlock
    __interceptor___snprintf_chk
    __interceptor___sprintf_chk, aliases __sprintf_chk
    __interceptor___strxfrm_l
    __interceptor___vsnprintf_chk
    __interceptor___vsprintf_chk
    __interceptor___wcsxfrm_l, aliases __wcsxfrm_l
    __interceptor_fgets
    __interceptor_fputs, aliases fputs
    __interceptor_mprotect, aliases mprotect
    __interceptor_name_to_handle_at
    __interceptor_open_by_handle_at
    __interceptor_pthread_getname_np
    __interceptor_readlink
    __interceptor_readlinkat
    __interceptor_recvmmsg
    __interceptor_sendmmsg, aliases sendmmsg
    __interceptor_strxfrm, aliases strxfrm
    __interceptor_strxfrm_l
    __interceptor_wcsxfrm, aliases wcsxfrm
    __interceptor_wcsxfrm_l, aliases wcsxfrm_l
    __pthread_mutex_lock
    __pthread_mutex_unlock, aliases __interceptor___pthread_mutex_unlock
    __sanitizer_acquire_crash_state
    __snprintf_chk, aliases __interceptor___snprintf_chk
    __sprintf_chk
    __strxfrm_l, aliases __interceptor___strxfrm_l
    __tsan_get_report_tag
    __tsan_symbolize_external_ex
    __vsnprintf_chk, aliases __interceptor___vsnprintf_chk
    __vsprintf_chk, aliases __interceptor___vsprintf_chk
    __wcsxfrm_l
    fgets, aliases __interceptor_fgets
    fputs
    mprotect
    name_to_handle_at, aliases __interceptor_name_to_handle_at
    open_by_handle_at, aliases __interceptor_open_by_handle_at
    pthread_getname_np, aliases __interceptor_pthread_getname_np
    readlink, aliases __interceptor_readlink
    readlinkat, aliases __interceptor_readlinkat
    recvmmsg, aliases __interceptor_recvmmsg
    sendmmsg
    strxfrm
    strxfrm_l, aliases __interceptor_strxfrm_l
    wcsxfrm
    wcsxfrm_l

================ end of changes of 'libtsan.so.0.0.0'===============

The two __tsan_* symbols:

    __tsan_get_report_tag
    __tsan_symbolize_external_ex

are not emitted in GCC 9.  Similarly for liblsan, the SONAMEs are the same:

$ rpm -qpl liblsan-8.3.1-4.5.el8.x86_64.rpm 
/usr/lib64/liblsan.so.0
/usr/lib64/liblsan.so.0.0.0
$ rpm -qpl liblsan-9.1.1-2.3.el8.x86_64.rpm
/usr/lib64/liblsan.so.0
/usr/lib64/liblsan.so.0.0.0

$ abipkgdiff liblsan-8.3.1-4.5.el8.x86_64.rpm liblsan-9.1.1-2.3.el8.x86_64.rpm
================ changes of 'liblsan.so.0.0.0'===============
  Functions changes summary: 0 Removed, 0 Changed, 0 Added function
  Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
  Function symbols changes summary: 1 Removed, 1 Added function symbols not referenced by debug info
  Variable symbols changes summary: 0 Removed, 0 Added variable symbol not referenced by debug info

  1 Removed function symbol not referenced by debug info:

    _ZN11__sanitizer11CheckFailedEPKciS1_yy

  1 Added function symbol not referenced by debug info:

    __sanitizer_acquire_crash_state

================ end of changes of 'liblsan.so.0.0.0'===============
Comment 4 Marek Polacek 2019-09-24 13:27:03 UTC 
I thought we had time before GTS 9 GA but I can work on it today.
Comment 42 errata-xmlrpc 2019-11-05 21:14:11 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3440
Note You need to log in before you can comment on or make changes to this bug.