[Bug gdb/14202] New: BFD: reopening /tmp/9501_._navl_3.0.0.32-9657_amd64_plugins_ad.plg: No such file or directory

[Bug gdb/14202] New: BFD: reopening /tmp/9501_._navl_3.0.0.32-9657_amd64_plugins_ad.plg: No such file or directory

[tbuckley at isc8 dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14202

             Bug #: 14202
           Summary: BFD: reopening
                    /tmp/9501_._navl_3.0.0.32-9657_amd64_plugins_ad.plg:
                    No such file or directory
           Product: gdb
           Version: 7.4
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
        AssignedTo: unassigned@sourceware.org
        ReportedBy: tbuckley@isc8.com
    Classification: Unclassified


gdb console in netbeans 7.1.2 shows the following message:

=library-loaded,id="/tmp/9501_._navl_3.0.0.32-9657_amd64_plugins_ad.plg",target-name="/tmp/9501_._navl_3.0.0.32-9657_amd64_plugins_ad.plg",host-name="/tmp/9501_._navl_3.0.0.32-9657_amd64_plugins_ad.plg",symbols-loaded="0",thread-group="i1"


later at a breakpoint I get:

=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0000000000450d03",func="idpi_tcp_reassembly_normal_processing",file="./turbodpi.66xx.navl/src/tcp_reassembly.c",fullname="/olddisk/home/tbuckley/work/tools/sensor_model/trunk/turbodpi.66xx.navl/src/tcp_reassembly.c",line="1449",times="1",original-location="/olddisk/home/tbuckley/work/tools/sensor_model/trunk/turbodpi.66xx.navl/src/tcp_reassembly.c:1449"}
~"[Switching to Thread 0x7ffbe37fe700 (LWP 9652)]\n"
*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x0000000000450d03",func="idpi_tcp_reassembly_normal_processing",args=[{name="work",value="0x7ffbe37fcad0"}],file="./turbodpi.66xx.navl/src/tcp_reassembly.c",fullname="/olddisk/home/tbuckley/work/tools/sensor_model/trunk/turbodpi.66xx.navl/src/tcp_reassembly.c",line="1450"},thread-id="13",stopped-threads="all",core="3"
=thread-selected,id="13"
(gdb) 
15-stack-list-frames
BFD: reopening /tmp/9501_._navl_3.0.0.32-9657_amd64_plugins_ad.plg: No such
file or directory


1. I know the navl library is stripped.
2. appears gdb thinks there should be a /tmp file, and there are no /tmp files
created in this debugging session.
3. Should gdb ignore the navl librarys.
4. If I remove the use of navl library from the software no problems.

Using Ubuntu 12.04, netbeans 7.1.2,GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2)
7.4-2012.04


Terry
tbuckley@isc8.com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14202] BFD: reopening /tmp/9501_._navl_3.0.0.32-9657_amd64_plugins_ad.plg: No such file or directory

[tbuckley at isc8 dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14202

Terry Buckley <tbuckley at isc8 dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |ubuntu 12.04
               Host|                            |ubuntu 12.04

--- Comment #1 from Terry Buckley <tbuckley at isc8 dot com> 2012-06-05 21:02:02 UTC ---
Complete gdb console is in netbeans pr 212902
Terry

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14202] BFD: reopening /tmp/9501_._navl_3.0.0.32-9657_amd64_plugins_ad.plg: No such file or directory

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14202

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at redhat dot com

--- Comment #2 from Tom Tromey <tromey at redhat dot com> 2012-06-12 19:49:04 UTC ---
(In reply to comment #0)
> gdb console in netbeans 7.1.2 shows the following message:
> 
> =library-loaded,id="/tmp/9501_._navl_3.0.0.32-9657_amd64_plugins_ad.plg"

This means gdb saw your program load this shared library.

> 15-stack-list-frames
> BFD: reopening /tmp/9501_._navl_3.0.0.32-9657_amd64_plugins_ad.plg: No such
> file or directory

At this point, gdb tries to reopen the library (not sure why, but there can
be various reasons); but at this point it has been deleted.

> 2. appears gdb thinks there should be a /tmp file, and there are no /tmp files
> created in this debugging session.

Apparently not the case.


gdb tries to lazily load debuginfo sections.  This could cause this problem --
but you say the file is stripped, so I would guess it is something else.
There's sort of a known problem here where BFD can close file descriptors and
reopen them, which is not always safe in scenarios like this.

One thing that might help is a stack trace at the point where gdb emits this
message.

I'm not entirely sure what to do in this area.  Changing BFD not to close fds
would be nice, but won't work on all hosts (or perhaps, I have heard, not
even all filesystems).  Eagerly mapping debuginfo sections might help (if that
is the bug here), but that hurts memory use always to support a relatively
obscure scenario (deleting a .so after dlopening it).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14202] BFD: reopening /tmp/9501_._navl_3.0.0.32-9657_amd64_plugins_ad.plg: No such file or directory

[tbuckley at isc8 dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14202

--- Comment #3 from Terry Buckley <tbuckley at isc8 dot com> 2012-06-13 14:01:56 UTC ---
(In reply to comment #2)
> (In reply to comment #0)
> > gdb console in netbeans 7.1.2 shows the following message:
> > 
> > =library-loaded,id="/tmp/9501_._navl_3.0.0.32-9657_amd64_plugins_ad.plg"
> 
> This means gdb saw your program load this shared library.
> 
> > 15-stack-list-frames
> > BFD: reopening /tmp/9501_._navl_3.0.0.32-9657_amd64_plugins_ad.plg: No such
> > file or directory
> 
> At this point, gdb tries to reopen the library (not sure why, but there can
> be various reasons); but at this point it has been deleted.
> 
> > 2. appears gdb thinks there should be a /tmp file, and there are no /tmp files
> > created in this debugging session.
> 
> Apparently not the case.
> 
> 
> gdb tries to lazily load debuginfo sections.  This could cause this problem --
> but you say the file is stripped, so I would guess it is something else.
> There's sort of a known problem here where BFD can close file descriptors and
> reopen them, which is not always safe in scenarios like this.
> 
> One thing that might help is a stack trace at the point where gdb emits this
> message.
> 
> I'm not entirely sure what to do in this area.  Changing BFD not to close fds
> would be nice, but won't work on all hosts (or perhaps, I have heard, not
> even all filesystems).  Eagerly mapping debuginfo sections might help (if that
> is the bug here), but that hurts memory use always to support a relatively
> obscure scenario (deleting a .so after dlopening it).

Tom,

Why does gdb keep track of a library that has been stripped and has no
information? Seems like it should ignore the plugins and when the breakpoint is
hit it will not have the problem of "No such file or directory"

Terry

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14202] BFD: reopening /tmp/9501_._navl_3.0.0.32-9657_amd64_plugins_ad.plg: No such file or directory

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14202

--- Comment #4 from Tom Tromey <tromey at redhat dot com> 2012-06-13 19:17:49 UTC ---
(In reply to comment #3)

> Why does gdb keep track of a library that has been stripped and has no
> information? Seems like it should ignore the plugins and when the breakpoint is
> hit it will not have the problem of "No such file or directory"

At least in my case it is reading .eh_frame:

#0  _bfd_default_error_handler (fmt=0x16cb019 "reopening %B: %s\n")
    at ../../archer/bfd/bfd.c:587
#1  0x0000000000994707 in bfd_cache_lookup_worker (abfd=0x2137680, 
    flag=CACHE_NO_SEEK) at ../../archer/bfd/cache.c:227
#2  0x00000000009947bc in cache_bseek (abfd=0x2137680, offset=1512, whence=0)
    at ../../archer/bfd/cache.c:244
#3  0x0000000000993d35 in bfd_seek (abfd=0x2137680, position=1512, 
    direction=0) at ../../archer/bfd/bfdio.c:327
#4  0x0000000000768f54 in dwarf2_read_section (objfile=0x2507ae0, info=
    0x250fe50) at ../../archer/gdb/dwarf2read.c:1748
#5  0x0000000000769371 in dwarf2_get_section_info (objfile=0x2507ae0, 
    sect=DWARF2_EH_FRAME, sectp=0x2510080, bufp=0x2510070, sizep=0x2510078)
    at ../../archer/gdb/dwarf2read.c:1855
#6  0x00000000007aaa38 in dwarf2_build_frame_info (objfile=0x2507ae0)
    at ../../archer/gdb/dwarf2-frame.c:2266
#7  0x00000000007a96ea in dwarf2_frame_find_fde (pc=0x7fffffffda80, 
    out_offset=0x0) at ../../archer/gdb/dwarf2-frame.c:1749
#8  0x00000000007a8dd0 in dwarf2_frame_sniffer (self=0xf4f1e0, this_frame=
    0x1fe4fd0, this_cache=0x1fe4fe8) at ../../archer/gdb/dwarf2-frame.c:1382
#9  0x0000000000817ca5 in frame_unwind_find_by_frame (this_frame=0x1fe4fd0, 
    this_cache=0x1fe4fe8) at ../../archer/gdb/frame-unwind.c:112


One idea might be to change how the BFD caching is done:
on "ok" systems, don't ever close the file descriptors, and on
other systems, eagerly map all sections.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14202] BFD: reopening /tmp/9501_._navl_3.0.0.32-9657_amd64_plugins_ad.plg: No such file or directory

[tbuckley at isc8 dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14202

--- Comment #5 from Terry Buckley <tbuckley at isc8 dot com> 2012-06-18 15:32:45 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> 
> > Why does gdb keep track of a library that has been stripped and has no
> > information? Seems like it should ignore the plugins and when the breakpoint is
> > hit it will not have the problem of "No such file or directory"
> 
> At least in my case it is reading .eh_frame:
> 
> #0  _bfd_default_error_handler (fmt=0x16cb019 "reopening %B: %s\n")
>     at ../../archer/bfd/bfd.c:587
> #1  0x0000000000994707 in bfd_cache_lookup_worker (abfd=0x2137680, 
>     flag=CACHE_NO_SEEK) at ../../archer/bfd/cache.c:227
> #2  0x00000000009947bc in cache_bseek (abfd=0x2137680, offset=1512, whence=0)
>     at ../../archer/bfd/cache.c:244
> #3  0x0000000000993d35 in bfd_seek (abfd=0x2137680, position=1512, 
>     direction=0) at ../../archer/bfd/bfdio.c:327
> #4  0x0000000000768f54 in dwarf2_read_section (objfile=0x2507ae0, info=
>     0x250fe50) at ../../archer/gdb/dwarf2read.c:1748
> #5  0x0000000000769371 in dwarf2_get_section_info (objfile=0x2507ae0, 
>     sect=DWARF2_EH_FRAME, sectp=0x2510080, bufp=0x2510070, sizep=0x2510078)
>     at ../../archer/gdb/dwarf2read.c:1855
> #6  0x00000000007aaa38 in dwarf2_build_frame_info (objfile=0x2507ae0)
>     at ../../archer/gdb/dwarf2-frame.c:2266
> #7  0x00000000007a96ea in dwarf2_frame_find_fde (pc=0x7fffffffda80, 
>     out_offset=0x0) at ../../archer/gdb/dwarf2-frame.c:1749
> #8  0x00000000007a8dd0 in dwarf2_frame_sniffer (self=0xf4f1e0, this_frame=
>     0x1fe4fd0, this_cache=0x1fe4fe8) at ../../archer/gdb/dwarf2-frame.c:1382
> #9  0x0000000000817ca5 in frame_unwind_find_by_frame (this_frame=0x1fe4fd0, 
>     this_cache=0x1fe4fe8) at ../../archer/gdb/frame-unwind.c:112
> 
> 
> One idea might be to change how the BFD caching is done:
> on "ok" systems, don't ever close the file descriptors, and on
> other systems, eagerly map all sections.

Tom,

Are you the person who would fix this problem. 

GDB needs to ignore any information from a stripped library, and never look at
it again.

GDB/BFD needs to ignore stripped libraries.

What happens next with this problem?

Terry

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug gdb/14202] BFD: reopening /tmp/9501_._navl_3.0.0.32-9657_amd64_plugins_ad.plg: No such file or directory

[srhaque at theiet dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14202

Shaheed Haque <srhaque at theiet dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |srhaque at theiet dot org

--- Comment #6 from Shaheed Haque <srhaque at theiet dot org> 2012-10-02 09:33:12 UTC ---
I'm on Ubuntu 12.10 (beta2) with GDB 7.5, and I am seeing what might be a
related problem, namely (names obscured to protect the innocent):

> gdb -ex='cd myworkspace' -ex='set sysroot mysysroot' -ex='target remote myhost:3964' myimage
GNU gdb (GDB) 7.5-ubuntu
Copyright (C) 2012 Free Software Foundation, Inc.
...
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from myimage...done.
Working directory myworkspace.
Remote debugging using myhost:3964
warning: Could not load shared library symbols for 7 libraries, e.g.
/lib/tls/libm.so.6.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
Reading symbols from mysysroot/pkg/lib/libfibipv4combine.so...done.
Loaded symbols for mysysroot/pkg/lib/libfibipv4combine.so
.
.
.
<Lots of libraries loaded ok>
.
.
.
Reading symbols from mysysroot/pkg/lib/libenf.so...done.
Loaded symbols for mysysroot/pkg/lib/libenf.so
BFD: reopening
/nobackup/shahhaqu/shahhaqu-lab1-CI-41-BUGFIX_NIGHTLY_11_04_03A/tgt-linux/pkg/lib/libcdm.so:
Operation not permitted

BFD: reopening
/nobackup/shahhaqu/shahhaqu-lab1-CI-41-BUGFIX_NIGHTLY_11_04_03A/tgt-linux/pkg/lib/libcdm.so:
Operation not permitted

BFD: reopening
/nobackup/shahhaqu/shahhaqu-lab1-CI-41-BUGFIX_NIGHTLY_11_04_03A/tgt-linux/pkg/lib/libcdm.so:
Operation not permitted


This carries on for a whole lot more libraries. Possibly relevant:

1. Sometimes, I seem to be able to workaround this by using "nosharedlibrary"
and "sharedlibrary" multiple times (I haver not managed to establish a
consistent pattern yet).

2. All these files are mounted via sshfs, i..e both the image and the
libraries.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.