GDB abort on glibc detected file descriptor overflow

GDB abort on glibc detected file descriptor overflow

[Ananthakrishna Sowda (asowda)]

I’m observing abort in GDB 9.2.1 version, and same issue is present in git://sourceware.org/git/binutils-gdb.git tip.

The full call trace is shown at the end of this message.
In frame 7,  call to FD_SET is causing buffer overflow when commands from a GDB macro file are processed.

(gdb) frame 7
#7  0x000000000076978b in gdb_readline_no_editing (prompt=<optimized out>) at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/top.c:850
850               FD_SET (fd, &readfds);
(gdb) p fd
$1 = 1533

GDB is processing split dwarf  “.dwp” file for the main executable and processing some “.dwo” files in the workspace, which may have something to do with it.  GDB is opening a bunch of .debug files , one each for every  library  and the open file descriptors  go  past 1024.  This results in buffer overflow when gdb.macros file is opened and processed in frame 7 ( file descriptor 1533).

The bfd file descriptor caching code which tries to limit no of open descriptors is not effective in this case.
Does this explanation make  sense? Any ideas to fix this issue are greatly appreciated.



Full backtrace leading up to abort:
(gdb) bt
#0  0x00007f6e8b4aa7ff in raise () from /lib64/libc.so.6
#1  0x00007f6e8b494c35 in abort () from /lib64/libc.so.6
#2  0x00007f6e8b4ed987 in __libc_message () from /lib64/libc.so.6
#3  0x00007f6e8b580935 in __fortify_fail_abort () from /lib64/libc.so.6
#4  0x00007f6e8b580967 in __fortify_fail () from /lib64/libc.so.6
#5  0x00007f6e8b57e926 in __chk_fail () from /lib64/libc.so.6
#6  0x00007f6e8b58085b in __fdelt_warn () from /lib64/libc.so.6
#7  0x000000000076978b in gdb_readline_no_editing (prompt=<optimized out>) at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/top.c:850
#8  command_line_input [_Z18command_line_inp...] (prompt_arg=<optimized out>, annotation_suffix=0xa2c00a "")
    at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/top.c:1336
#9  0x0000000000769b22 in read_command_file [_Z17read_command_fil...] (stream=stream@entry=0x63b3d360)
    at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/top.c:455
#10 0x00000000004d912d in script_from_file [_Z16script_from_file...] (stream=stream@entry=0x63b3d360,
    file=file@entry=0x2b78337 "/tmp/gdb.macros") at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/cli/cli-script.c:1622
#11 0x00000000004ce37b in source_script_from_stream (file_to_open=0x2b78337 “/tmp/gdb.macros",
    file=0x2b78337 "/tmp/gdb.macros", stream=0x63b3d360) at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/cli/cli-cmds.c:660
#12 source_script_with_search [_ZL25source_script_w...] (file=0x2b78337 "/tmp/gdb.macros", from_tty=<optimized out>,
    search_path=<optimized out>) at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/cli/cli-cmds.c:696
#13 0x00000000004ce4d8 in source_command [_ZL14source_commandP...] (args=<optimized out>, from_tty=0)
    at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/cli/cli-cmds.c:755
#14 0x00000000004d1652 in cmd_func [_Z8cmd_funcP16cmd_li...] (cmd=<optimized out>, args=<optimized out>, from_tty=<optimized out>)
    at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/cli/cli-decode.c:1952
#15 0x0000000000768dea in execute_command [_Z15execute_commandP...] (p=<optimized out>,
    p@entry=0x2b78330 "source /tmp/gdb.macros", from_tty=0) at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/top.c:666
#16 0x000000000056784c in command_handler [_Z15command_handlerP...] (command=0x2b78330 "source /tmp/gdb.macros")
    at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/event-top.c:587
#17 0x0000000000769b2f in read_command_file [_Z17read_command_fil...] (stream=stream@entry=0x2af4a30)
    at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/top.c:458
#18 0x00000000004d912d in script_from_file [_Z16script_from_file...] (stream=stream@entry=0x2af4a30,
    file=file@entry=0x7fffeccca944 "/ws/asowda-sjc/tmp/gdbinit") at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/cli/cli-script.c:1622
#19 0x00000000004ce37b in source_script_from_stream (file_to_open=0x7fffeccca944 "/ws/asowda-sjc/tmp/gdbinit",
    file=0x7fffeccca944 "/ws/asowda-sjc/tmp/gdbinit", stream=0x2af4a30) at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/cli/cli-cmds.c:660
#20 source_script_with_search [_ZL25source_script_w...] (file=0x7fffeccca944 "/ws/asowda-sjc/tmp/gdbinit",
    file@entry=<error reading variable: value has been optimized out>, from_tty=<error reading variable: value has been optimized out>,
    search_path=<error reading variable: value has been optimized out>) at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/cli/cli-cmds.c:696
#21 0x00000000006042fe in catch_command_errors [_ZL20catch_command_e...] (command=<optimized out>, arg=<optimized out>, from_tty=<optimized out>)
    at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/main.c:400
#22 0x0000000000605555 in captured_main_1 [_ZL15captured_main_1...] (context=<optimized out>)
    at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/main.c:1163
#23 0x0000000000605c5b in captured_main (data=data@entry=0x7fffeccc9dc0) at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/main.c:1217
#24 gdb_main [_Z8gdb_mainP18captur...] (args=args@entry=0x7fffeccc9de0) at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/main.c:1217
#25 0x000000000042a4d5 in main (argc=<optimized out>, argv=<optimized out>) at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/gdb.c:32

Re: GDB abort on glibc detected file descriptor overflow

[Simon Marchi]

On 2021-09-01 6:37 p.m., Ananthakrishna Sowda (asowda) via Gdb wrote:
> I’m observing abort in GDB 9.2.1 version, and same issue is present in git://sourceware.org/git/binutils-gdb.git tip.
> 
> The full call trace is shown at the end of this message.
> In frame 7,  call to FD_SET is causing buffer overflow when commands from a GDB macro file are processed.
> 
> (gdb) frame 7
> #7  0x000000000076978b in gdb_readline_no_editing (prompt=<optimized out>) at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/top.c:850
> 850               FD_SET (fd, &readfds);
> (gdb) p fd
> $1 = 1533
> 
> GDB is processing split dwarf  “.dwp” file for the main executable and processing some “.dwo” files in the workspace, which may have something to do with it.  GDB is opening a bunch of .debug files , one each for every  library  and the open file descriptors  go  past 1024.  This results in buffer overflow when gdb.macros file is opened and processed in frame 7 ( file descriptor 1533).
> 
> The bfd file descriptor caching code which tries to limit no of open descriptors is not effective in this case.
> Does this explanation make  sense? Any ideas to fix this issue are greatly appreciated.

It won't fix the problem, but I think we could start by adding an
assertion before calling FD_SET (everywhere where we do call it):

  gdb_assert (fd < FD_SETSIZE);

Your build happened to catch it, but other builds could just fail
silently or crash in less clear ways.

As for the solution, maybe this code should be converted to use poll or
other more modern APIs to avoid this limit?

It would be interesting if you could show what are the open file
descriptors at this point (list /proc/<pid>/fd), just to see what uses
the most fds.

Simon

Re: GDB abort on glibc detected file descriptor overflow

[Ananthakrishna Sowda (asowda)]

I looked in /proc/<pid>/fd for Gdb process and I see 1535 files open. Most of them are pointing to libfoo.so and libfoo.so.debug , where libfoo.so is a library loaded by the process which crashed and generated a core-file. Normally, these file descriptors are re-used and maximum number of open file descriptors stays around 150, even for a process which could load several hundreds of .so libraries.


From: Simon Marchi <simon.marchi@polymtl.ca>
Date: Wednesday, September 1, 2021 at 6:05 PM
To: Ananthakrishna Sowda (asowda) <asowda@cisco.com>, gdb@sourceware.org <gdb@sourceware.org>
Subject: Re: GDB abort on glibc detected file descriptor overflow


On 2021-09-01 6:37 p.m., Ananthakrishna Sowda (asowda) via Gdb wrote:
> I’m observing abort in GDB 9.2.1 version, and same issue is present in git://sourceware.org/git/binutils-gdb.git tip.
>
> The full call trace is shown at the end of this message.
> In frame 7,  call to FD_SET is causing buffer overflow when commands from a GDB macro file are processed.
>
> (gdb) frame 7
> #7  0x000000000076978b in gdb_readline_no_editing (prompt=<optimized out>) at /auto/swtools/prod-builds/src/gdb-9.2.1/gdb/gdb/top.c:850
> 850               FD_SET (fd, &readfds);
> (gdb) p fd
> $1 = 1533
>
> GDB is processing split dwarf  “.dwp” file for the main executable and processing some “.dwo” files in the workspace, which may have something to do with it.  GDB is opening a bunch of .debug files , one each for every  library  and the open file descriptors  go  past 1024.  This results in buffer overflow when gdb.macros file is opened and processed in frame 7 ( file descriptor 1533).
>
> The bfd file descriptor caching code which tries to limit no of open descriptors is not effective in this case.
> Does this explanation make  sense? Any ideas to fix this issue are greatly appreciated.

It won't fix the problem, but I think we could start by adding an
assertion before calling FD_SET (everywhere where we do call it):

  gdb_assert (fd < FD_SETSIZE);

Your build happened to catch it, but other builds could just fail
silently or crash in less clear ways.

As for the solution, maybe this code should be converted to use poll or
other more modern APIs to avoid this limit?

It would be interesting if you could show what are the open file
descriptors at this point (list /proc/<pid>/fd), just to see what uses
the most fds.

Simon