Bug 29449 - Crash on load when the target does not support shared libraries
Summary: Crash on load when the target does not support shared libraries
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: HEAD
: P2 critical
Target Milestone: 13.1
Assignee: Tom Tromey
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-08-05 16:19 UTC by Tsukasa OI
Modified: 2022-08-09 02:36 UTC (History)
2 users (show)

See Also:
Host: x86_64-unknown-linux-gnu
Target: riscv64-unknown-elf, x86_64-unknown-elf
Build: x86_64-unknown-linux-gnu
Last reconfirmed: 2022-08-08 00:00:00


Attachments
patch (306 bytes, patch)
2022-08-08 15:13 UTC, Tom Tromey
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tsukasa OI 2022-08-05 16:19:38 UTC
Commit: master (99c902690493e35aad16b2083bad34cf79c366bf)
Target (Reproduced):
-   x86_64-unknown-elf
-   riscv64-unknown-elf
Target (NOT Reproduced):
-   x86_64-unknown-linux-gnu
-   riscv64-linux-gnu

When a target file (possibly with symbols?) is loaded, GDB crashes.

Excerpts from GDB is as follows (I used `gdb --batch -x a.txt' to reproduce the bug quickly but it's just a file command):

Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x000055555598fa44 in solib_create_inferior_hook (from_tty=0) at /home/builduser/src/binutils-gdb/gdb/solib.c:1274
1274      ops->solib_create_inferior_hook (from_tty);
(gdb) bt
#0  0x000055555598fa44 in solib_create_inferior_hook (from_tty=0) at /home/builduser/src/binutils-gdb/gdb/solib.c:1274
#1  0x00005555559be0a6 in symbol_file_command (args=<optimized out>, from_tty=0) at /home/builduser/src/binutils-gdb/gdb/symfile.c:1655
#2  0x00005555557f3aa1 in file_command (arg=0x555556009d95 "targets/opensbi/fw_dynamic.elf", from_tty=0) at /home/builduser/src/binutils-gdb/gdb/exec.c:555
#3  0x000055555570b7f5 in cmd_func (cmd=<optimized out>, args=<optimized out>, from_tty=<optimized out>) at /home/builduser/src/binutils-gdb/gdb/cli/cli-decode.c:2516
#4  0x0000555555a0f5c1 in execute_command (p=<optimized out>, p@entry=0x555556009d90 "file targets/opensbi/fw_dynamic.elf", from_tty=0) at /home/builduser/src/binutils-gdb/gdb/top.c:699
#5  0x00005555557f0215 in command_handler (command=0x555556009d90 "file targets/opensbi/fw_dynamic.elf") at /home/builduser/src/binutils-gdb/gdb/event-top.c:598
#6  0x0000555555a1075f in read_command_file (stream=stream@entry=0x55555611ef90) at /home/builduser/src/binutils-gdb/gdb/top.c:468
#7  0x000055555571a6f4 in script_from_file (stream=stream@entry=0x55555611ef90, file=file@entry=0x7fffffffe532 "a.txt") at /home/builduser/src/binutils-gdb/gdb/cli/cli-script.c:1625
#8  0x0000555555708193 in source_script_from_stream (file_to_open=0x7fffffffdd30 "a.txt", file=0x7fffffffe532 "a.txt", stream=0x55555611ef90) at /home/builduser/src/binutils-gdb/gdb/cli/cli-cmds.c:715
#9  source_script_with_search (file=0x7fffffffe532 "a.txt", 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 /home/builduser/src/binutils-gdb/gdb/cli/cli-cmds.c:760
#10 0x0000555555883e23 in catch_command_errors (command=<optimized out>, arg=<optimized out>, from_tty=<optimized out>, do_bp_actions=<optimized out>) at /home/builduser/src/binutils-gdb/gdb/main.c:513
#11 0x0000555555883eb8 in execute_cmdargs (cmdarg_vec=cmdarg_vec@entry=0x7fffffffdeb0, file_type=file_type@entry=CMDARG_FILE, cmd_type=cmd_type@entry=CMDARG_COMMAND, ret=ret@entry=0x7fffffffdea4) at /home/builduser/src/binutils-gdb/gdb/main.c:605
#12 0x000055555588593d in captured_main_1 (context=<optimized out>) at /home/builduser/src/binutils-gdb/gdb/main.c:1298
#13 0x000055555588650f in captured_main (data=0x7fffffffe0c0) at /home/builduser/src/binutils-gdb/gdb/main.c:1319
#14 gdb_main (args=args@entry=0x7fffffffe0f0) at /home/builduser/src/binutils-gdb/gdb/main.c:1344
#15 0x0000555555635e00 in main (argc=<optimized out>, argv=<optimized out>) at /home/builduser/src/binutils-gdb/gdb/gdb.c:32
(gdb)


I bisected and found that commit cb275538dbddfbb3c2c372a665ac48e6f617ea33 is the cause of this bug.

I think this crash happens when there's no shared library support (where default solib data must be used and no one calls the set_solib_ops function).  The same commit with x86_64-unknown-linux-gnu and riscv64-linux-gnu targets were fine.
For such cases, current_target_so_ops should be used but... this is not used anywhere, causing NULL target_so_ops to be used.

The only reason I haven't submitted the patch to fix this bug is because I haven't completed the copyright assignment for my GDB contribution.
I think I shared enough information to reproduce and fix this bug but tell me if not.
Comment 1 Tom Tromey 2022-08-08 15:13:48 UTC
Created attachment 14262 [details]
patch

I suspect this will work but I haven't been able to reproduce the bug yet.
Comment 2 Sourceware Commits 2022-08-08 16:06:49 UTC
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ce81f9d6fa885a3faa41613debc8771304dc469b

commit ce81f9d6fa885a3faa41613debc8771304dc469b
Author: Tom Tromey <tromey@adacore.com>
Date:   Mon Aug 8 09:56:47 2022 -0600

    Fix regression from gdbarch registry change
    
    The gdbarch registry patch introduced a regression that could cause a
    crash when opening files in gdb.  The bug is that, previously, the
    solib ops would default to current_target_so_ops; but the patch
    changed this code to default to nullptr.  This patch fixes the bug by
    reintroducing the earlier behavior.  This is PR gdb/29449.
    
    I managed to reproduce the bug with a riscv-elf build and then
    verified that this fixes the problem.
    
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29449
Comment 3 Tom Tromey 2022-08-08 16:07:50 UTC
Fixed.
Comment 4 Tsukasa OI 2022-08-09 02:36:48 UTC
I confirmed that the bug is fixed (yes, my internal patch also touched that function).  I apologize that I should have noted the detailed procedure to reproduce.

Anyway, thanks for fixing this!