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
Complete gdb console is in netbeans pr 212902 Terry
(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).
(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
(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.
(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
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.