0

In a docker container with disk full gdb takes a while starting. It takes a very long while starting for large binary & large core dumps.

It is emitting errors like "error: db5 error(28) from dbenv->open: No space left on device". Grepping the internet shows that error is associated with yum/rpm.

I just want a quick backtrace from the core dump initially.

How can I prevent gdb doing whatever initialisation it is doing? (presumably loading debug symbols for shared/linked libraries).

Note that while it is loading / being slow Ctrl-C doesn't work. Ctrl-Z (suspend) does work so you can always suspend and kill the command if it is taking too long.

[root@XXX]# gdb -c core.XXX bin/XXX
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-94.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from bin/XXX...
done.
[New LWP 19938]
[New LWP 20044]
.
.
error: db5 error(28) from dbenv->open: No space left on device
error: cannot open Packages index using db5 - No space left on device (28)
error: cannot open Packages database in 
error: db5 error(28) from dbenv->open: No space left on device
error: cannot open Packages database in 
error: db5 error(28) from dbenv->open: No space left on device
error: cannot open Packages database in 
error: db5 error(28) from dbenv->open: No space left on device
error: cannot open Packages database in 
error: db5 error(28) from dbenv->open: No space left on device
error: cannot open Packages database in 
error: db5 error(28) from dbenv->open: No space left on device
error: cannot open Packages database in 
Missing separate debuginfo for /lib64/libm.so.6
Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/72/1c7cc9488efa25f83b48af713ab27dbe48ef3e.debug
error: db5 error(28) from dbenv->open: No space left on device
error: cannot open Packages database in 
.
.

Possibly related but . . .
Tell gdb to skip standard files

Community
  • 1
  • 1
gaoithe
  • 4,218
  • 3
  • 30
  • 38
  • 4
    why not free up some disk space ? – Sander De Dycker Apr 20 '17 at 12:10
  • It is mainly the core dump using all the disk space. yes core could be copied out and opened external to container but I would like to find the fastest and laziest way of getting backtrace. – gaoithe Apr 20 '17 at 12:12
  • What gdb does on startup - https://sourceware.org/gdb/current/onlinedocs/gdb/Startup.html#Startup and https://sourceware.org/gdb/onlinedocs/gdb/Auto_002dloading.html are interesting. Still getting db5 error with 'gdb -q -iex "set auto-load off" -c core bbin' though. – gaoithe Apr 20 '17 at 12:22
  • @Sander De Dycker THanks. You have the best answer. Free up disk space or copy core files off and open. I couldn't make gdb do it while the disk was full :-P. – gaoithe Apr 20 '17 at 12:30
  • And unfortunately pstack doesn't work on core files in linux. I know of no alternative to gdb to get a backtrace from a core dump on linux. – Sander De Dycker Apr 20 '17 at 12:38

1 Answers1

0

These errors don't come from gdb itself, but rather from some library coming from RPM. Some distros, like Fedora, patch gdb to have it look up which libraries might have separate debuginfo that has not been installed.

There's no way to disable this in the gdb you already have. However, you could build your own gdb that does not have this patch applied. This would solve the problem you are seeing.

Tom Tromey
  • 21,507
  • 2
  • 45
  • 63