Bug 593686 - [6.0] Unexpected failure of resolving a locally-defined symbol.
Summary: [6.0] Unexpected failure of resolving a locally-defined symbol.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: glibc
Version: 6.0
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Andreas Schwab
QA Contact: Petr Muller
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-19 13:54 UTC by Alan Matsuoka
Modified: 2018-10-27 13:55 UTC (History)
4 users (show)

Fixed In Version: glibc-2.12-1.3.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-10 20:29:01 UTC
Target Upstream Version:


Attachments (Terms of Use)
reproducer.tar.gz (941 bytes, application/x-gzip)
2010-05-19 13:55 UTC, Alan Matsuoka
no flags Details
reproducer_v2.tar.gz (964 bytes, application/x-gzip)
2010-05-19 13:56 UTC, Alan Matsuoka
no flags Details
sosreport-rhel6a3x-20100325135947-819e.tar.bz2 (1.46 MB, application/x-bzip2)
2010-05-19 13:57 UTC, Alan Matsuoka
no flags Details

Description Alan Matsuoka 2010-05-19 13:54:17 UTC
Issue:   	 RHN System ID:

Customer Contact Name:
Naoki Yanagimoto

Description of Problem:
This problem is the same as issue #580553 of RHEL5.
This ticket is for RHEL6.

We hit a failure of resolving a symbol which is locally defined in a library,
in a complex case that I'll describe below.
If the dynamic linker, glibc or something else has a bug in it, please fix it.

We wrote a program that consists of an executable file and four libraries.
The executable file a.out requires two libraries, libA and libX.
The library libA requires another library libB.
The library libB requires another library libC.

The program operates in the following steps.

+------+      +-------+      +------+    +------+      +-----------------------------------+
| libX |  (2) | a.out | (1)  | libA |----| libB |------| libC  (5)        (7)              |
|      | <=== |  (8)  | ===> |      |    |      | <=== | atexit(libC_fini)--> _libC_fini() |
+------+  (3) +-------+ (6)  +------+    +------+  (4) +-----------------------------------+

(1) a.out calls dlopen() for libA.
    libB and libC shall be loaded, too.
(2) a.out calls dlopen() for libX.
(3) a.out calls dlclose() for libX.
(4) libC calls dlopen() for libB.
(5) libC calls atexit() to register libC_fini().
(6) a.out calls dlclose() for libA.
    libB and libC are no longer needed, so both libraries shall be getting unloaded.
(7) libC_fini() shall be called when libC is getting unloaded.
(8) a.out exits.

But when we run the program, unexpectedly

 a) step (7) is executed _after_ step (8)
 b) libC cannot resolve a locally-defined symbol _libC_fini at executing (7)

Version-Release number of selected component:
- Red Hat Enterprise Linux Version Number: 6
- Release Number: Alpha 3
- Architecture: x86
- Kernel Version: 2.6.31-38.el6
- Related Package Version: glibc-2.10.90-26
- Related Middleware / Application: None

Drivers or hardware or architecture dependency:
None.

How reproducible:
always.

Step to Reproduce:
1) Extract the reproducer.
   $ tar zxvf reproducer.tar.gz

2) Compile it.
   $ cd reproducer
   $ make

3) Run it.
   $ ./run.sh

Actual Results:
$ ./run.sh
1)main:dlopen  libA.so
2)main:dlopen  libX.so
3)main:dlclose libX.so
4)libC:dlopen  libB.so
5)libC:atexit(libC_fini)
6)main:dlclose libA.so
8)main:finish main
./main: symbol lookup error: ./libC.so: undefined symbol: _libC_fini

Expected Results:
$ ./run.sh
1)main:dlopen  libA.so
2)main:dlopen  libX.so
3)main:dlclose libX.so
4)libC:dlopen  libB.so
5)libC:atexit(libC_fini)
6)main:dlclose libA.so
7)libC:finish - atexit()
8)main:finish main

Summary of actions taken to resolve issue:
None.

Location of diagnostic data:
None.

Hardware configuration:
Model: PRIMERGY RX300 S5
CPU Info: Xeon(R) 2.27GHz x2
Memory Info: 3GB
Hardware Component Information: None
Configuration Info: None
Guest Configuration Info: None

Business Impact:
The application suffering this issue cannot call the function registered
by atexit() because of the failure of resolving its symbol. It causes two
severe problems, a) the failure of cooperation with other processes by
notifying them of its completion, and b) the system resource leaks by not
freeing them.

Target Release: 6.0

Errata Request: None.

Hotfix Request: None.

Additional Info:
Sosreport and reproducer are attached.

Sosreport and reproducer are attached.
> 3)
>
> Why does calling libC_fini() succeed even though calling _libC_fini() fails?
>
> Ans:
> For the same reasons as above.

This answer does not satisfy us.
It just answered "Why calling _libC_fini() fails", but here we want to know
"Why calling libC_fini() succeeds" instead. They are completely different
questions.

> 4)
>
> Here is another program "reproducer_v2.tar.gz" that works well without any
> "undefined symbol" error. We provide it, too.
> The difference between "reproducer" and "reproducer_v2" is whether to call
> dlopen()/dlclose for libX.so or not. The "reproducer_v2" does not call them.
> According to your explanation, it is a problem if "reproducer_v2" works well
> without any problem, because the RTLD_GLOBAL flag is not specified in it.
> Why does this work well?
>
> Ans:
> I'm looking further into this

We add some information of differences between them.

If a.out does not call dlopen()/dlclose() for libX.so ["reproducer_v2" case]:
- When libA.so is closed, dlclose() updates the l_scope list of libC.so.
- There is the scope for libC.so in the l_scope list (in the linkmap structure)
of libC.so itself after a.out calls dlclose() for libA.so.

If a.out calls dlopen()/dlclose() for libX.so ["reproducer" case]:
- When libA.so is closed, dlclose() doesn't update the l_scope list of libC.so.
- There is no scope for libC.so in the l_scope list of any library (even
libC.so itself) after a.out calls dlclose() for libA.so.

So obviously there is something wrong in dlclose().

Comment 1 Alan Matsuoka 2010-05-19 13:55:41 UTC
Created attachment 415113 [details]
reproducer.tar.gz

Comment 2 Alan Matsuoka 2010-05-19 13:56:10 UTC
Created attachment 415114 [details]
reproducer_v2.tar.gz

Comment 3 Alan Matsuoka 2010-05-19 13:57:46 UTC
Created attachment 415116 [details]
sosreport-rhel6a3x-20100325135947-819e.tar.bz2

Comment 4 RHEL Program Management 2010-05-19 14:16:03 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 8 releng-rhel@redhat.com 2010-11-10 20:29:01 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.


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