Bug 1973747 - Unexpected behavior when using DT_FILTER
Summary: Unexpected behavior when using DT_FILTER
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: glibc
Version: 8.4
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: beta
: ---
Assignee: glibc team
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-06-18 15:44 UTC by Andrew Mike
Modified: 2023-07-18 14:30 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-12-10 14:50:57 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
reproducer test case from upstream Sourceware Bugzilla (1.50 KB, application/zip)
2021-06-18 15:44 UTC, Andrew Mike
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Sourceware 27977 0 P2 UNCONFIRMED Unexpected behavior when using DT_FILTER 2022-10-28 13:11:24 UTC

Description Andrew Mike 2021-06-18 15:44:39 UTC
Created attachment 1792089 [details]
reproducer test case from upstream Sourceware Bugzilla

Description of problem: Runtime linker does not honor DT_FILTER.

Version-Release number of selected component (if applicable):
2.28-151.el8

How reproducible: 100%

Steps to Reproduce:
1. Download and extract attached reproducer test case.
2. Change to directory and run "make main".
3. Run "./main".

Actual results: main calls func1() from lib2.so

Expected results: main calls func1() from lib1.so

Additional info: Upstream bug description (https://sourceware.org/bugzilla/show_bug.cgi?id=27977#c0) has rationale.

Comment 1 Florian Weimer 2021-06-28 09:37:55 UTC
There has been quite a bit discussion on the upstream ticket: https://sourceware.org/bugzilla/show_bug.cgi?id=27977

I don't know if the customer is already involved there. While this is clearly a bug in our DT_FILTER implementation, I need to clarify that this unlikely to be fixed anytime soon. Even if we (or someone else) develops an upstream fix for this issue, we don't know yet how backportable it will be.

If the symbol collision involves a Red-Hat-provided library, maybe we should consider renaming that symbol instead. But it seems that the customer is dealing with two different pieces of third-party software.

Comment 2 Carlos O'Donell 2021-12-10 14:50:57 UTC
I'm marking this bug CLOSED UPSTREAM and we will track this upstream in the sourceware bug 27977:
https://sourceware.org/bugzilla/show_bug.cgi?id=27977


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