From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 704EC3858D37; Mon, 19 Sep 2022 13:03:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 704EC3858D37 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1663592585; bh=xhS+X1v25WtZ+OO+L39EhOphw4GuFZvpHrDFgQxivV8=; h=From:To:Subject:Date:From; b=Oma5Sb+/6ZaiK+SEp4xwLWUM/n2XS8sxqiMxoajAQWdo7f1cjiQ3+/M51EpDgYuWa wCdFhT7n2vYvUM6jtfHRAKVeMaSY5Hy6rOefPMYwN/Lwcv6XrSvI4Gas9PR9PuZiCX pt87Iy8om33sv05N/Cp6pgu7HnFOw2zgah9X9Oto= From: "mcopik at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug shlibs/29586] New: Debugger hangs on a shared library in memory-mapped file. Date: Mon, 19 Sep 2022 13:03:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: shlibs X-Bugzilla-Version: 12.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mcopik at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29586 Bug ID: 29586 Summary: Debugger hangs on a shared library in memory-mapped file. Product: gdb Version: 12.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: shlibs Assignee: unassigned at sourceware dot org Reporter: mcopik at gmail dot com Target Milestone: --- Hi! We have an application that sends code to remote executors by transmitting = the shared library as a binary payload between executors. The shared library da= ta is written to a memory-mapped file, and we pass the file descriptor to dlop= en. This works fine in our use case. However, we learned recently that this set= up prevents us from using gdb when trying to debug the code. We noticed that gdb hangs when trying to execute a function obtained from a shared library when memory-mapped files are used. If we replace the call to dlopen with a regular one, gdb processes the application correctly. We attached gdb instance to the hanged gdb instance. When we build gdb from source in debug mode, we find out that gdb hangs on a call to fread in its internal cache of file descriptors (see the output below). We reproduced the issue on gdb version 12.0.90-0ubuntu1, then on the offici= al release 12.1. To reproduce the problem, run `build.sh` to compile the shared library from lib.c and the two versions of the `main.c`. The script creates= two executables: `from_file` works fine with gdb, and `from_memory` is the one reproducing the problem.=20 Gist with all source code samples: https://gist.github.com/mcopik/c6dc64e6b24aea9576d517ca00d1a9c0 Hanged gdb sessions: (gdb) r Starting program: /home/mcopik/bug_report/from_memory=20 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Reading from /proc/self/fd/4 Attached gdb session: Attaching to process 573765 [New LWP 573767] [New LWP 573768] [New LWP 573769] [New LWP 573770] [New LWP 573771] [New LWP 573772] [New LWP 573773] [New LWP 573774] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". __GI___libc_read (nbytes=3D4096, buf=3D0x558434f1b220, fd=3D15) at ../sysdeps/unix/sysv/linux/read.c:26 26 ../sysdeps/unix/sysv/linux/read.c: No such file or directory. (gdb) bt #0 __GI___libc_read (nbytes=3D4096, buf=3D0x558434f1b220, fd=3D15) at ../sysdeps/unix/sysv/linux/read.c:26 #1 __GI___libc_read (fd=3D15, buf=3D0x558434f1b220, nbytes=3D4096) at ../sysdeps/unix/sysv/linux/read.c:24 #2 0x00007f82b8697cb6 in _IO_new_file_underflow (fp=3D0x558434e4f2c0) at ./libio/libioP.h:947 #3 0x00007f82b86964b8 in __GI__IO_file_xsgetn (fp=3D0x558434e4f2c0, data=3D, n=3D64) at ./libio/fileops.c:1321 #4 0x00007f82b868ac29 in __GI__IO_fread (buf=3Dbuf@entry=3D0x7ffc32027bb0, size=3Dsize@entry=3D1, count=3Dcount@entry=3D64, fp=3Dfp@entry=3D0x558434e4= f2c0) at ./libio/iofread.c:38 #5 0x000055843364f53e in fread (__stream=3D0x558434e4f2c0, __n=3D64, __siz= e=3D1, __ptr=3D0x7ffc32027bb0) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:293 #6 cache_bread_1 (nbytes=3D64, buf=3D0x7ffc32027bb0, f=3D0x558434e4f2c0) at cache.c:319 #7 cache_bread (abfd=3D, buf=3D0x7ffc32027bb0, nbytes=3D64)= at cache.c:358 #8 0x000055843364e564 in bfd_bread (ptr=3Dptr@entry=3D0x7ffc32027bb0, size=3D, size@entry=3D64, abfd=3D, abfd@entry=3D0x558434f0f210) at bfdio.c:259 #9 0x000055843366ca53 in bfd_elf64_object_p (abfd=3D0x558434f0f210) at /home/mcopik/bug_report/build/gdb-12.1/bfd/elfcode.h:519 #10 0x000055843365199c in bfd_check_format_matches (abfd=3D0x558434f0f210, format=3D, matching=3D0x0) at format.c:344 #11 0x000055843351edfe in solib_bfd_open (pathname=3D0x558434e90200 "/proc/self/fd/4") at ./../gdbsupport/gdb_ref_ptr.h:130 #12 0x000055843351dee7 in solib_map_sections (so=3D0x558434f0ff00) at solib= .c:540 #13 0x000055843351fe56 in update_solib_list (from_tty=3D) at solib.c:860 #14 0x0000558433520877 in solib_add (pattern=3Dpattern@entry=3D0x0, from_tty=3Dfrom_tty@entry=3D0, readsyms=3D1) at solib.c:960 #15 0x0000558433520b00 in handle_solib_event () at solib.c:1269 #16 0x0000558433252165 in bpstat_stop_status (aspace=3D, bp_addr=3Dbp_addr@entry=3D140737353900800, thread=3Dthread@entry=3D0x558434= ddf090, ws=3D...,=20 stop_chain=3Dstop_chain@entry=3D0x0) at breakpoint.c:5455 #17 0x00005584333dbc8b in handle_signal_stop (ecs=3D0x7ffc32028700) at infrun.c:6191 #18 0x00005584333dda68 in handle_stop_requested (ecs=3D) at infrun.c:4465 #19 handle_stop_requested (ecs=3D) at infrun.c:4460 #20 handle_inferior_event (ecs=3D0x7ffc32028700) at infrun.c:5695 #21 0x00005584333df48e in fetch_inferior_event () at infrun.c:4085 #22 0x00005584336f7ef6 in gdb_wait_for_event (block=3Dblock@entry=3D0) at event-loop.cc:700 #23 0x00005584336f83da in gdb_wait_for_event (block=3D0) at event-loop.cc:5= 96 #24 gdb_do_one_event () at event-loop.cc:212 #25 0x0000558433424275 in start_event_loop () at main.c:421 #26 captured_command_loop () at main.c:481 #27 0x0000558433425e75 in captured_main (data=3D0x7ffc320288a0) at main.c:1= 351 #28 gdb_main (args=3Dargs@entry=3D0x7ffc320288d0) at main.c:1366 #29 0x00005584331b9d10 in main (argc=3D, argv=3D) at gdb.c:32 System: Linux master-node 5.15.0-47-generic #51-Ubuntu SMP Thu Aug 11 07:51= :15 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux Compiler: gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0 GDB configuration: x86_64-pc-linux-gnu" --=20 You are receiving this mail because: You are on the CC list for the bug.=