Bug 86464 - "Error while mapping shared library" error
Summary: "Error while mapping shared library" error
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gdb
Version: 8.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Elena Zannoni
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-03-23 01:56 UTC by Bob Flavin
Modified: 2007-04-18 16:52 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-10-18 14:52:43 UTC
Embargoed:


Attachments (Terms of Use)

Description Bob Flavin 2003-03-23 01:56:48 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

Description of problem:
GDB complains of not being able to find a share library file:

  Error while mapping shared library sections:

Here is the fix:

About 38 lines into solib_open in solib.c  there are three lines
that look like:
  
  if (found_file < 0 && solib_search_path != NULL)

for searching various directories, I think they were copied one from 
another and that the second and third should not refer to solib_search_path,
but should refer to 'get_in_environ (inferior_environ, "PATH")' and
'get_in_environ (inferior_environ, "LD_LIBRARY_PATH")' respectively.

Perhaps the following code would be suitable (if get_in_environ returns a
null if the env var is not defined):

/* If not found, next search the solib_search_path (if any).  */
if (found_file < 0 && solib_search_path != NULL)
found_file = openp (solib_search_path,
  1, in_pathname, O_RDONLY, 0, &temp_pathname);

/* If not found, next search the inferior's $PATH environment variable. */
p = get_in_environ (inferior_environ, "PATH");
if (found_file < 0 && p != NULL)
found_file = openp (p, 1, in_pathname, O_RDONLY, 0, &temp_pathname);

/* If not found, next search the inferior's $LD_LIBRARY_PATH
environment variable. */
p = get_in_environ (inferior_environ, "LD_LIBRARY_PATH");
if (found_file < 0 && p != NULL)
found_file = openp (p, 1, in_pathname, O_RDONLY, 0, &temp_pathname);


The bug that this fixes is that the following error message:

  Error while mapping shared library sections:

was incorrectly generated because solib_open failed to find libraries that
were listed in env var "PATH".  (The second call to openp was skipped
because solib_search_path was being tested when it should have looked
for PATH in inferior_environ.


Version-Release number of selected component (if applicable):
GNU gdb Red Hat Linux (5.2.1-4)

How reproducible:
Always

Steps to Reproduce:
1. (debug core while with shared in an unusual place)
2.
3.
    

Additional info:

Comment 1 Elena Zannoni 2003-04-07 22:03:34 UTC
Could you please add some more precise steps to reproduce the problem? 
And a log of the failing gdb?

Comment 2 Bill Skaggs 2004-05-19 19:19:03 UTC
This happens to me whenever I run gdb on my freshly installed FC2,
even on newly compiled code.  This is a very high priority bug to me!
 Here is what it looks like:

[bill@localhost bill]$ gdb ~/bin/xplot
GNU gdb Red Hat Linux (6.0post-0.20040223.19rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host
libthread_db library "/lib/tls/libthread_db.so.1".
 
(gdb) run
Starting program: /home/bill/bin/xplot
Error while mapping shared library sections:
: Success.
Error while reading shared library symbols:
: No such file or directory.
Error while reading shared library symbols:
: No such file or directory.
Error while reading shared library symbols:
: No such file or directory.
Error while reading shared library symbols:
: No such file or directory.
Error while reading shared library symbols:
: No such file or directory.
Error while reading shared library symbols:
: No such file or directory.
Error while reading shared library symbols:
: No such file or directory.
etc . . .

Comment 3 Joaquin Cuenca Abela 2004-07-27 14:48:47 UTC
Idem for me.
It happens to me when I compile a .so (for example. libfoo.so), put it
in a directory ($(gen)), link the executable against this .so
(-L$(gen) -Wl,-rpath,"" ... -lfoo).

I use rpath because at the end I copy the .so in the same directory as
the executable.

gdb don't reads the shared library symbols of these so files.

Am I doing something wrong, or is it gdb's fault?

Cheers,

Comment 4 Bob Flavin 2004-07-27 16:11:08 UTC
Yes, it is gdb's fault.  I supplied the fix and an explanation of 
what the bug is.  Couldn't the gdb team just incorporate the fix into 
the code?  If you look at the current code, it is clearly wrong.

I don't have a simple example demonstrate the problem, but then the 
debugging is already done.

Comment 5 Bill Nottingham 2006-08-07 17:50:15 UTC
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Red Hat apologizes that these issues have not been resolved yet. We do
want to make sure that no important bugs slip through the cracks.
Please check if this issue is still present in a current Fedora Core
release. If so, please change the product and version to match, and
check the box indicating that the requested information has been
provided. Note that any bug still open against Red Hat Linux on will be
closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.


Comment 6 Bill Nottingham 2006-10-18 14:52:43 UTC
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Closing as CANTFIX.


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