[Bug gdb/23697] New: Python Exception <class 'gdb.error'> Can't read data for section '.debug_loc' in file '….debug' after BFD: reopening ….debug: No such file or directory

[traumschuleriebau at riseup dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=23697

Bug ID: 23697
Summary: Python Exception <class 'gdb.error'> Can't read data
for section '.debug_loc' in file '….debug' after BFD:
reopening ….debug: No such file or directory
Product: gdb
Version: 8.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gdb
Assignee: unassigned at sourceware dot org
Reporter: traumschuleriebau at riseup dot net
Target Milestone: ---
Host: debian
Target: debian

A long running application crashed and "thread apply all bt full" caused gdb to
fail to prompt. The underlying issue is related to #14202.

From my perspective gdb should not fail hard when a .debug file disappeared for
example because a dbgsym package got updated by the package manager in the
meantime and paths have changed. It might be impossible to find out the updated
path but an error would be nice to not loose a trace.

The issue with pidgin is tracked at https://developer.pidgin.im/ticket/17341

Steps taken are described at https://developer.pidgin.im/wiki/GetABacktrace

Debian package tracker https://tracker.debian.org/pkg/gdb

~$ gdb pidgin 2>&1 | tee ~/pidgin-backtrace.log
(gdb) handle SIGPIPE nostop noprint
(gdb) run

...

Thread 1 "pidgin" received signal SIGSEGV, Segmentation fault.
0xb7fc0516 in purple_websocket_send (ws=0x1270e10, op=PURPLE_WEBSOCKET_PONG,
msg=0x0, len=0) at purple-websocket.c:67
67 return &b->buf[l];
(gdb) thread apply all bt full

Thread 4 (Thread 0xb0bffb40 (LWP 25040)):
BFD: reopening
/usr/lib/debug/.build-id/75/af2e83b092c11b3b3bce5af892bc54f0555d63.debug: No
such file or directory

BFD: reopening
/usr/lib/debug/.build-id/75/af2e83b092c11b3b3bce5af892bc54f0555d63.debug: No
such file or directory

BFD: reopening
/usr/lib/debug/.build-id/75/af2e83b092c11b3b3bce5af892bc54f0555d63.debug: No
such file or directory

BFD: reopening
/usr/lib/debug/.build-id/6b/f189e869243d4014c6e9b590278ec7afea7901.debug: No
such file or directory

BFD: reopening
/usr/lib/debug/.build-id/6b/f189e869243d4014c6e9b590278ec7afea7901.debug: No
such file or directory

BFD: reopening
/usr/lib/debug/.build-id/6b/f189e869243d4014c6e9b590278ec7afea7901.debug: No
such file or directory

Python Exception <class 'gdb.error'> Can't read data for section '.debug_loc'
in file
'/usr/lib/debug/.build-id/6b/f189e869243d4014c6e9b590278ec7afea7901.debug':
~$
<back to prompt without writing a core file>

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23697

Tom Tromey <tromey at sourceware dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at sourceware dot org

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---

BFD: reopening /usr/lib/debug/.build-id/75/af2e83b092c11b3b3bce5af892bc54f0555d63.debug: No such file or directory

I think this should only happen if this file exists and is used by
gdb, then is deleted during the debug session. For a separate debug
file in particular this seems odd.

See also bug 14202.

I suspect we should just declare the lazy mapping idea to have
been a failure and go back to eagerly mapping all the needed
debug sections in dwarf2read.c.