Bug 13490 - Dynamically loading Fortran fails
Summary: Dynamically loading Fortran fails
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc
Version: 6.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-07-05 08:08 UTC by Plummer, Martyn
Modified: 2007-04-18 16:27 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-10-02 18:48:17 UTC
Embargoed:


Attachments (Terms of Use)

Description Plummer, Martyn 2000-07-05 08:08:33 UTC
Dynamically loading shared objects compiled from Fortran may fail with an
undefined symbol message.  The symbol string returned by dlerror is garbage
and this sometimes leads to a segmentation fault.

This problem has been reported on the mailing lists of the R language
(http://www.r-project.org). R has a facility for users to create
dynamically loaded "packages" to extend the functionality of the language.
Many of these packages contain Fortran code.

The problem is specific to Red Hat 6.2 and has not been reproduced on other
platforms.  It only occurs with packages that contain Fortran code.

Here is an example, which is reproducible.  You can download an RPM
of R from
http://www.r-project.org/bin/linux/redhat/6.x/i386/R-base-1.1.0-2.i386.rpm
The source for the tseries package can be downloaded from
http://www.r-project.org/src/contrib/tseries_0.5-2.tar.gz
To install the tseries package, type (as root)
R CMD INSTALL tseries_0.5-2.tar.gz
The launch R within gdb by typing "R -d gdb" and at the R prompt type
"library(tseries)" to load the tseries package


Here is a stack trace:

$ R -d gdb
...
(gdb) set args --vanilla
(gdb) r
Starting program: /usr/lib/R/bin/R.bin --vanilla
...
> library(tseries)

Program received signal SIGSEGV, Segmentation fault.
_dl_lookup_symbol (undef_name=0x81f52f60 <Address 0x81f52f60 out of
bounds>, 
    ref=0xbfffaae0, symbol_scope=0x81edab4, 
    reference_name=0x81ea018 "/home/martyn/Rlibs/tseries/libs/tseries.so", 
    reloc_type=18) at ../sysdeps/generic/dl-hash.h:31
31	../sysdeps/generic/dl-hash.h: No such file or directory.
(gdb) bt
#0  _dl_lookup_symbol (
    undef_name=0x81f52f60 <Address 0x81f52f60 out of bounds>,
ref=0xbfffaae0, 
    symbol_scope=0x81edab4, 
    reference_name=0x81ea018 "/home/martyn/Rlibs/tseries/libs/tseries.so", 
    reloc_type=18) at ../sysdeps/generic/dl-hash.h:31
#1  0x400096ad in _dl_relocate_object (l=0x81ed8b0, scope=0x81edab4,
lazy=0, 
    consider_profiling=0) at ../sysdeps/i386/dl-machine.h:326
#2  0x40191be4 in dl_open_worker (a=0xbfffac4c) at dl-open.c:182
#3  0x4000ac3b in _dl_catch_error (errstring=0xbfffac48, 
    operate=0x40191990 <dl_open_worker>, args=0xbfffac4c) at dl-error.c:141
#4  0x40191d3d in _dl_open (
    file=0xbfffbdec "/home/martyn/Rlibs/tseries/libs/tseries.so", mode=2, 
    caller=0xbfffac48) at dl-open.c:232
#5  0x400503d3 in dlopen_doit (a=0xbfffad5c) at dlopen.c:41
#6  0x4000ac3b in _dl_catch_error (errstring=0x40052080, 
    operate=0x400503a8 <dlopen_doit>, args=0xbfffad5c) at dl-error.c:141
#7  0x400508b9 in _dlerror_run (operate=0x400503a8 <dlopen_doit>, 
    args=0xbfffad5c) at dlerror.c:125

#8  0x40050393 in __dlopen_check (
    file=0xbfffbdec "/home/martyn/Rlibs/tseries/libs/tseries.so", mode=2)
    at dlopen.c:53
#9  0x80e4b3a in AddDLL (
    path=0xbfffbdec "/home/martyn/Rlibs/tseries/libs/tseries.so",
    asLocal=1, now=1) at dynload.c:207

Comment 1 Klaus Steinberger 2001-02-25 18:52:59 UTC
This bug also happens when loading dynamic modules into ROOT system (see
http://root.cern.ch/).
If we compile an link a dynamic FORTRAN module with a RedHat 6.0 system, the
resulting bynary
could be dynamically loaded into ROOT on a RH6.2 system. But if we link the
module on RH6.2
it will fail. Note that probably the linking process of the dynamic module is
the problem point,
as module compile under RH6.0 but linked on RH6.2 fails, but a module compiled
under RH6.2
but linked under RH6.0 works!

Please increase the priority of this bug, as we urgently need this functionality
in RH 6.2

Comment 2 Klaus Steinberger 2001-02-26 12:35:34 UTC
We did further investigation in this case. A downgrade to
binutils-2.9.1.0.23-6.i386 from Redhat-6.1
did solve our problem. So the problem is related to binutils. We also tried the
following versions of
binutils:  binutils-2.9.5.0.22-6.i386 built from RH 6.2 ssrc.rpm without the
ldsymver path, which fails too.
Also binutils-2.10.1 from gnu.org fails. So there must be some change between
2.9.1.0.23 and 2.9.5.0.22
which triggers the problem.

We can work around now with the downgraded binutils, but as we do not know which
others side effects
we will encounter,  as well as we are afraid that this bug will hit us again
with RH-7.x please consider fixing it
properly.

Sincerly,
Klaus Steinberger



Comment 3 Jakub Jelinek 2004-10-02 18:48:17 UTC
If you can see the problem with contemporary gcc/binutils, please
reopen.


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