* [Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects
2024-08-13 13:16 [Bug breakpoints/32079] New: Can't insert internal breakpoints after inferior dlclose some share objects blarsen at redhat dot com
@ 2024-08-14 12:19 ` ssbssa at sourceware dot org
2024-08-14 13:11 ` blarsen at redhat dot com
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ssbssa at sourceware dot org @ 2024-08-14 12:19 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=32079
Hannes Domani <ssbssa at sourceware dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ssbssa at sourceware dot org
--- Comment #1 from Hannes Domani <ssbssa at sourceware dot org> ---
Does dlmopen(LM_ID_NEWLM) load a 2nd CRT in this case?
Because some time ago I noticed a very similar looking problem on Windows if I
load & unload a 2nd CRT.
Using this example:
```
#include <windows.h>
#include <stdio.h>
int main()
{
HMODULE mod = LoadLibrary ("ucrtbase.dll");
FreeLibrary (mod);
printf ("hi\n");
return 0;
}
```
This happens when I step through it:
```
C:\src\tests>gdb64 gdb-32079.exe
Reading symbols from gdb-32079.exe...
(gdb) start
Temporary breakpoint 1 at 0x140001581: file gdb-32079.c, line 6.
Starting program: C:\src\tests\gdb-32079.exe
Temporary breakpoint 1, main () at gdb-32079.c:6
6 HMODULE mod = LoadLibrary ("ucrtbase.dll");
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00000000777b1000 0x00000000779584e0 Yes (*)
C:\Windows\SYSTEM32\ntdll.dll
0x0000000077691000 0x00000000777aeab8 Yes (*)
C:\Windows\system32\kernel32.dll
0x000007fefd691000 0x000007fefd6fb13c Yes (*)
C:\Windows\system32\KernelBase.dll
0x000007feff6d1000 0x000007feff76e4bc Yes (*)
C:\Windows\system32\msvcrt.dll
(*): Shared library is missing debugging information.
(gdb) maint info breakpoints
Num Type Disp Enb Address What
-4 longjmp master keep n 0x0000000077800fa0 <ntdll!longjmp> inf 1
-4.1 y- 0x0000000077800fa0 <ntdll!longjmp> inf 1
-5 longjmp master keep n 0x000007feff6de540 <msvcrt!longjmp> inf 1
-5.1 y- 0x000007feff6de540 <msvcrt!longjmp> inf 1
(gdb) n
7 FreeLibrary (mod);
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00000000777b1000 0x00000000779584e0 Yes (*)
C:\Windows\SYSTEM32\ntdll.dll
0x0000000077691000 0x00000000777aeab8 Yes (*)
C:\Windows\system32\kernel32.dll
0x000007fefd691000 0x000007fefd6fb13c Yes (*)
C:\Windows\system32\KernelBase.dll
0x000007feff6d1000 0x000007feff76e4bc Yes (*)
C:\Windows\system32\msvcrt.dll
0x000007fee6b11000 0x000007fee6c01b04 Yes (*)
C:\Windows\system32\ucrtbase.dll
0x000007fee6b01000 0x000007fee6b023f0 Yes (*)
C:\Windows\system32\api-ms-win-core-timezone-l1-1-0.dll
0x000007fee6af1000 0x000007fee6af23f0 Yes (*)
C:\Windows\system32\api-ms-win-core-file-l2-1-0.dll
0x000007fee6ae1000 0x000007fee6ae23f0 Yes (*)
C:\Windows\system32\api-ms-win-core-localization-l1-2-0.dll
0x000007fef05e1000 0x000007fef05e23f0 Yes (*)
C:\Windows\system32\api-ms-win-core-synch-l1-2-0.dll
0x000007fee6ad1000 0x000007fee6ad23f0 Yes (*)
C:\Windows\system32\api-ms-win-core-processthreads-l1-1-1.dll
0x000007fee6ac1000 0x000007fee6ac23f0 Yes (*)
C:\Windows\system32\api-ms-win-core-file-l1-2-0.dll
(*): Shared library is missing debugging information.
(gdb) maint info breakpoints
Num Type Disp Enb Address What
-24 longjmp master keep n 0x0000000077800fa0 <ntdll!longjmp> inf 1
-24.1 y- 0x0000000077800fa0 <ntdll!longjmp> inf 1
-25 longjmp master keep n 0x000007feff6de540 <msvcrt!longjmp> inf 1
-25.1 y- 0x000007feff6de540 <msvcrt!longjmp> inf 1
-26 longjmp master keep n 0x000007fee6b431c0 <ucrtbase!longjmp> inf 1
-26.1 y- 0x000007fee6b431c0 <ucrtbase!longjmp> inf 1
(gdb) n
warning: error removing breakpoint 0 at 0x7fee6b431c0
9 printf ("hi\n");
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00000000777b1000 0x00000000779584e0 Yes (*)
C:\Windows\SYSTEM32\ntdll.dll
0x0000000077691000 0x00000000777aeab8 Yes (*)
C:\Windows\system32\kernel32.dll
0x000007fefd691000 0x000007fefd6fb13c Yes (*)
C:\Windows\system32\KernelBase.dll
0x000007feff6d1000 0x000007feff76e4bc Yes (*)
C:\Windows\system32\msvcrt.dll
(*): Shared library is missing debugging information.
(gdb) maint info breakpoints
Num Type Disp Enb Address What
-24 longjmp master keep n 0x0000000077800fa0 <ntdll!longjmp> inf 1
-24.1 y- 0x0000000077800fa0 <ntdll!longjmp> inf 1
-25 longjmp master keep n 0x000007feff6de540 <msvcrt!longjmp> inf 1
-25.1 y- 0x000007feff6de540 <msvcrt!longjmp> inf 1
-26 longjmp master keep n 0x000007fee6b431c0 inf 1
-26.1 y- 0x000007fee6b431c0 inf 1
(gdb) n
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x7fee6b431c0
Command aborted.
(gdb) maint info breakpoints
Num Type Disp Enb Address What
-24 longjmp master keep n 0x0000000077800fa0 <ntdll!longjmp> inf 1
-24.1 y- 0x0000000077800fa0 <ntdll!longjmp> inf 1
-25 longjmp master keep n 0x000007feff6de540 <msvcrt!longjmp> inf 1
-25.1 y- 0x000007feff6de540 <msvcrt!longjmp> inf 1
-26 longjmp master keep n 0x000007fee6b431c0 inf 1
-26.1 y- 0x000007fee6b431c0 inf 1
0 longjmp keep y 0x0000000077800fa0 <ntdll!longjmp> inf 1
stop only in thread 1
0.1 y 0x0000000077800fa0 <ntdll!longjmp> inf 1
0 longjmp keep y 0x000007feff6de540 <msvcrt!longjmp> inf 1
stop only in thread 1
0.1 y 0x000007feff6de540 <msvcrt!longjmp> inf 1
0 longjmp keep y 0x000007fee6b431c0 inf 1
stop only in thread 1
0.1 y 0x000007fee6b431c0 inf 1
```
So there was an additional internal breakpoint set on ucrtbase!longjmp, but it
wasn't removed when ucrtbase was unloaded.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects
2024-08-13 13:16 [Bug breakpoints/32079] New: Can't insert internal breakpoints after inferior dlclose some share objects blarsen at redhat dot com
2024-08-14 12:19 ` [Bug breakpoints/32079] " ssbssa at sourceware dot org
@ 2024-08-14 13:11 ` blarsen at redhat dot com
2024-08-16 19:42 ` ssbssa at sourceware dot org
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: blarsen at redhat dot com @ 2024-08-14 13:11 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=32079
--- Comment #2 from Guinevere Larsen <blarsen at redhat dot com> ---
I do see multiple instances of libc after dlopen-ing libraries in a new linker
namespace (CRTs, as you called them - only spelling it out for others that
might be confused like me ;)
It seems that GDB is trying to re-insert shlib event breakpoints into the libc
from the second namespace that now no longer exists. We probably need GDB to
recognize that that namespace is no longer valid... or we can try to be more
generic, and in case we try to insert (certain types of?) internal breakpoints
in a PC that has no object associated with it, we just delete the breakpoint
instead.
For extra debugging, this is the output of `info shared` and the internal
breakpoints added by GDB:
```
(gdb) info shared
From To Syms Read Shared Object Library
0x00007ffff7fc9000 0x00007ffff7ff09f5 Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7ed2440 0x00007ffff7f49666 Yes (*) /lib64/libm.so.6
0x00007ffff7cf9800 0x00007ffff7e65cfd Yes (*) /lib64/libc.so.6
0x00007ffff7fbc040 0x00007ffff7fbc129 Yes
/home/gwenthekween/Documents/upstream-build/gdb/testsuite/outputs
/gdb.base/dlmopen/dlmopen-lib.1.so
0x00007ffff7fb7040 0x00007ffff7fb70f9 Yes
/home/gwenthekween/Documents/upstream-build/gdb/testsuite/outputs
/gdb.base/dlmopen/dlmopen-lib-dep.so
0x00007ffff7be0440 0x00007ffff7c57666 Yes (*) /lib64/libm.so.6
0x00007ffff7a07800 0x00007ffff7b73cfd Yes (*) /lib64/libc.so.6
0x00007ffff7fc9000 0x00007ffff7ff09f5 Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7fa8040 0x00007ffff7fa8129 Yes
/home/gwenthekween/Documents/upstream-build/gdb/testsuite/outputs
/gdb.base/dlmopen/dlmopen-lib.1.so
0x00007ffff7cca040 0x00007ffff7cca0f9 Yes
/home/gwenthekween/Documents/upstream-build/gdb/testsuite/outputs
/gdb.base/dlmopen/dlmopen-lib-dep.so
0x00007ffff78f1440 0x00007ffff7968666 Yes (*) /lib64/libm.so.6
0x00007ffff7718800 0x00007ffff7884cfd Yes (*) /lib64/libc.so.6
0x00007ffff7fc9000 0x00007ffff7ff09f5 Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7cc5040 0x00007ffff7cc5129 Yes
/home/gwenthekween/Documents/upstream-build/gdb/testsuite/outputs
/gdb.base/dlmopen/dlmopen-lib.2.so
(*): Shared library is missing debugging information.
(gdb) maint info breakpoints
Num Type Disp Enb Address What
-40 shlib events keep n 0x00007ffff7fe7edf <dl_main+6271> inf 1
-40.1 y- 0x00007ffff7fe7edf <dl_main+6271> inf 1
-41 shlib events keep y 0x00007ffff7fe83ba <dl_main+7514> inf 1
-41.1 y 0x00007ffff7fe83ba <dl_main+7514> inf 1
-42 shlib events keep n 0x00007ffff7fd04e5
<_dl_map_object_from_fd+4213> inf 1
-42.1 y- 0x00007ffff7fd04e5
<_dl_map_object_from_fd+4213> inf 1
-43 shlib events keep y 0x00007ffff7fd5177 <dl_open_worker_begin+1191>
inf 1
-43.1 y 0x00007ffff7fd5177 <dl_open_worker_begin+1191>
inf 1
-44 shlib events keep n 0x00007ffff7fc9f13 <_dl_close_worker+1859> inf
1
-44.1 y- 0x00007ffff7fc9f13 <_dl_close_worker+1859> inf
1
-45 shlib events keep y 0x00007ffff7fca1ca <_dl_close_worker+2554> inf
1
-45.1 y 0x00007ffff7fca1ca <_dl_close_worker+2554> inf
1
-70 longjmp master keep n 0x00007ffff7df79b9 <____longjmp_chk+249> inf 1
-70.1 y- 0x00007ffff7df79b9 <____longjmp_chk+249> inf 1
-71 longjmp master keep n 0x00007ffff7d11b57 <__longjmp_cancel+55> inf 1
-71.1 y- 0x00007ffff7d11b57 <__longjmp_cancel+55> inf 1
-72 longjmp master keep n 0x00007ffff7d11ad3 <__longjmp+163> inf 1
-72.1 y- 0x00007ffff7d11ad3 <__longjmp+163> inf 1
-73 longjmp master keep n 0x00007ffff7b059b9 <____longjmp_chk+249> inf 1
-73.1 y- 0x00007ffff7b059b9 <____longjmp_chk+249> inf 1
-74 longjmp master keep n 0x00007ffff7a1fb57 <__longjmp_cancel+55> inf 1
-74.1 y- 0x00007ffff7a1fb57 <__longjmp_cancel+55> inf 1
-75 longjmp master keep n 0x00007ffff7a1fad3 <__longjmp+163> inf 1
-75.1 y- 0x00007ffff7a1fad3 <__longjmp+163> inf 1
-76 longjmp master keep n 0x00007ffff78169b9 <____longjmp_chk+249> inf 1
-76.1 y- 0x00007ffff78169b9 <____longjmp_chk+249> inf 1
-77 longjmp master keep n 0x00007ffff7730b57 <__longjmp_cancel+55> inf 1
-77.1 y- 0x00007ffff7730b57 <__longjmp_cancel+55> inf 1
-78 longjmp master keep n 0x00007ffff7730ad3 <__longjmp+163> inf 1
-78.1 y- 0x00007ffff7730ad3 <__longjmp+163> inf 1
3 breakpoint keep y 0x000000000040130b
/home/gwenthekween/Documents/upstream-build/gdb/testsuite/../../..
/binutils-gdb/gdb/testsuite/gdb.base/dlmopen.c:61 inf 1
breakpoint already hit 2 times
3.1 y 0x000000000040130b
/home/gwenthekween/Documents/upstream-build/gdb/testsuite/../../..
/binutils-gdb/gdb/testsuite/gdb.base/dlmopen.c:61 inf 1
(gdb) n
warning: error removing breakpoint 0 at 0x7ffff78169b9
warning: error removing breakpoint 0 at 0x7ffff7730b57
warning: error removing breakpoint 0 at 0x7ffff7730ad3
54 for (dl = 0; dl < 4; ++dl)
```
And the results after closing handle[2] (which closes the linker namespace)
are:
```
(gdb) info shared
From To Syms Read Shared Object Library
0x00007ffff7fc9000 0x00007ffff7ff09f5 Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7ed2440 0x00007ffff7f49666 Yes (*) /lib64/libm.so.6
0x00007ffff7cf9800 0x00007ffff7e65cfd Yes (*) /lib64/libc.so.6
0x00007ffff7fbc040 0x00007ffff7fbc129 Yes
/home/gwenthekween/Documents/upstream-build/gdb/testsuite/outputs
/gdb.base/dlmopen/dlmopen-lib.1.so
0x00007ffff7fb7040 0x00007ffff7fb70f9 Yes
/home/gwenthekween/Documents/upstream-build/gdb/testsuite/outputs
/gdb.base/dlmopen/dlmopen-lib-dep.so
0x00007ffff7be0440 0x00007ffff7c57666 Yes (*) /lib64/libm.so.6
0x00007ffff7a07800 0x00007ffff7b73cfd Yes (*) /lib64/libc.so.6
0x00007ffff7fc9000 0x00007ffff7ff09f5 Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7cc5040 0x00007ffff7cc5129 Yes
/home/gwenthekween/Documents/upstream-build/gdb/testsuite/outputs
/gdb.base/dlmopen/dlmopen-lib.2.so
(*): Shared library is missing debugging information.
(gdb) maint info breakpoints
Num Type Disp Enb Address What
-40 shlib events keep n 0x00007ffff7fe7edf <dl_main+6271> inf 1
-40.1 y- 0x00007ffff7fe7edf <dl_main+6271> inf 1
-41 shlib events keep y 0x00007ffff7fe83ba <dl_main+7514> inf 1
-41.1 y 0x00007ffff7fe83ba <dl_main+7514> inf 1
-42 shlib events keep n 0x00007ffff7fd04e5
<_dl_map_object_from_fd+4213> inf 1
-42.1 y- 0x00007ffff7fd04e5
<_dl_map_object_from_fd+4213> inf 1
-43 shlib events keep y 0x00007ffff7fd5177 <dl_open_worker_begin+1191>
inf 1
-43.1 y 0x00007ffff7fd5177 <dl_open_worker_begin+1191>
inf 1
-44 shlib events keep n 0x00007ffff7fc9f13 <_dl_close_worker+1859> inf
1
-44.1 y- 0x00007ffff7fc9f13 <_dl_close_worker+1859> inf
1
-45 shlib events keep y 0x00007ffff7fca1ca <_dl_close_worker+2554> inf
1
-45.1 y 0x00007ffff7fca1ca <_dl_close_worker+2554> inf
1
-70 longjmp master keep n 0x00007ffff7df79b9 <____longjmp_chk+249> inf 1
-70.1 y- 0x00007ffff7df79b9 <____longjmp_chk+249> inf 1
-71 longjmp master keep n 0x00007ffff7d11b57 <__longjmp_cancel+55> inf 1
-71.1 y- 0x00007ffff7d11b57 <__longjmp_cancel+55> inf 1
-72 longjmp master keep n 0x00007ffff7d11ad3 <__longjmp+163> inf 1
-72.1 y- 0x00007ffff7d11ad3 <__longjmp+163> inf 1
-73 longjmp master keep n 0x00007ffff7b059b9 <____longjmp_chk+249> inf 1
-73.1 y- 0x00007ffff7b059b9 <____longjmp_chk+249> inf 1
-74 longjmp master keep n 0x00007ffff7a1fb57 <__longjmp_cancel+55> inf 1
-74.1 y- 0x00007ffff7a1fb57 <__longjmp_cancel+55> inf 1
-75 longjmp master keep n 0x00007ffff7a1fad3 <__longjmp+163> inf 1
-75.1 y- 0x00007ffff7a1fad3 <__longjmp+163> inf 1
-76 longjmp master keep n 0x00007ffff78169b9 inf 1
-76.1 y- 0x00007ffff78169b9 inf 1
-77 longjmp master keep n 0x00007ffff7730b57 inf 1
-77.1 y- 0x00007ffff7730b57 inf 1
-78 longjmp master keep n 0x00007ffff7730ad3 inf 1
-78.1 y- 0x00007ffff7730ad3 inf 1
3 breakpoint keep y 0x000000000040130b
/home/gwenthekween/Documents/upstream-build/gdb/testsuite/../../..
/binutils-gdb/gdb/testsuite/gdb.base/dlmopen.c:61 inf 1
breakpoint already hit 3 times
3.1 y 0x000000000040130b
/home/gwenthekween/Documents/upstream-build/gdb/testsuite/../../..
/binutils-gdb/gdb/testsuite/gdb.base/dlmopen.c:61 inf 1
```
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects
2024-08-13 13:16 [Bug breakpoints/32079] New: Can't insert internal breakpoints after inferior dlclose some share objects blarsen at redhat dot com
2024-08-14 12:19 ` [Bug breakpoints/32079] " ssbssa at sourceware dot org
2024-08-14 13:11 ` blarsen at redhat dot com
@ 2024-08-16 19:42 ` ssbssa at sourceware dot org
2024-08-19 20:36 ` woodard at redhat dot com
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ssbssa at sourceware dot org @ 2024-08-16 19:42 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=32079
--- Comment #3 from Hannes Domani <ssbssa at sourceware dot org> ---
I came up with this:
```
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -8049,6 +8049,7 @@ static void
disable_breakpoints_in_unloaded_shlib (program_space *pspace, const solib
&solib)
{
bool disabled_shlib_breaks = false;
+ bool remove_disabled_longjmp_breaks = false;
for (bp_location *loc : all_bp_locations ())
{
@@ -8059,6 +8060,8 @@ disable_breakpoints_in_unloaded_shlib (program_space
*pspace, const solib &solib
&& !loc->shlib_disabled
&& (((b->type == bp_breakpoint
|| b->type == bp_jit_event
+ || b->type == bp_longjmp
+ || b->type == bp_longjmp_master
|| b->type == bp_hardware_breakpoint)
&& (loc->loc_type == bp_loc_hardware_breakpoint
|| loc->loc_type == bp_loc_software_breakpoint))
@@ -8071,6 +8074,13 @@ disable_breakpoints_in_unloaded_shlib (program_space
*pspace, const solib &solib
to prevent future errors occurring in remove_breakpoints. */
loc->inserted = 0;
+ if (b->type == bp_longjmp
+ || b->type == bp_longjmp_master)
+ {
+ remove_disabled_longjmp_breaks = true;
+ continue;
+ }
+
/* This may cause duplicate notifications for the same breakpoint.
*/
notify_breakpoint_modified (b);
@@ -8084,6 +8094,12 @@ disable_breakpoints_in_unloaded_shlib (program_space
*pspace, const solib &solib
disabled_shlib_breaks = true;
}
}
+
+ if (remove_disabled_longjmp_breaks)
+ for (breakpoint &b : all_breakpoints_safe ())
+ if ((b.type == bp_longjmp || b.type == bp_longjmp_master)
+ && b.first_loc ().shlib_disabled)
+ delete_breakpoint (&b);
}
/* Disable any breakpoints and tracepoints in OBJFILE upon
```
I'm not completely sure if it's the correct approach to fix this, but it works
for Windows at least.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects
2024-08-13 13:16 [Bug breakpoints/32079] New: Can't insert internal breakpoints after inferior dlclose some share objects blarsen at redhat dot com
` (2 preceding siblings ...)
2024-08-16 19:42 ` ssbssa at sourceware dot org
@ 2024-08-19 20:36 ` woodard at redhat dot com
2024-08-23 17:06 ` tromey at sourceware dot org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: woodard at redhat dot com @ 2024-08-19 20:36 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=32079
Ben Woodard <woodard at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |woodard at redhat dot com
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects
2024-08-13 13:16 [Bug breakpoints/32079] New: Can't insert internal breakpoints after inferior dlclose some share objects blarsen at redhat dot com
` (3 preceding siblings ...)
2024-08-19 20:36 ` woodard at redhat dot com
@ 2024-08-23 17:06 ` tromey at sourceware dot org
2024-08-30 11:22 ` aburgess at redhat dot com
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: tromey at sourceware dot org @ 2024-08-23 17:06 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=32079
Tom Tromey <tromey at sourceware dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at sourceware dot org
--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
If this happens with longjmp breakpoints, it can probably
happen with the C++ exception breakpoints as well.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects
2024-08-13 13:16 [Bug breakpoints/32079] New: Can't insert internal breakpoints after inferior dlclose some share objects blarsen at redhat dot com
` (4 preceding siblings ...)
2024-08-23 17:06 ` tromey at sourceware dot org
@ 2024-08-30 11:22 ` aburgess at redhat dot com
2025-02-24 11:02 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: aburgess at redhat dot com @ 2024-08-30 11:22 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=32079
Andrew Burgess <aburgess at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aburgess at redhat dot com
--- Comment #5 from Andrew Burgess <aburgess at redhat dot com> ---
I've posted a proposed fix for this bug here:
https://inbox.sourceware.org/gdb-patches/cover.1724948606.git.aburgess@redhat.com/
It is inspired by the changes Hannes Domani proposed in:
https://sourceware.org/bugzilla/show_bug.cgi?id=32079#c3
But when combined with an earlier patch in the series I don't think the
delete_breakpoint call is needed. And as Tom pointed out I handle more b/p
types as well as fixing another issue that cropped up during testing.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects
2024-08-13 13:16 [Bug breakpoints/32079] New: Can't insert internal breakpoints after inferior dlclose some share objects blarsen at redhat dot com
` (5 preceding siblings ...)
2024-08-30 11:22 ` aburgess at redhat dot com
@ 2025-02-24 11:02 ` cvs-commit at gcc dot gnu.org
2025-02-24 11:02 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2025-02-24 11:02 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=32079
--- Comment #6 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ffd09b625ef0970cf25d691e949b86b07a7e3cb1
commit ffd09b625ef0970cf25d691e949b86b07a7e3cb1
Author: Andrew Burgess <aburgess@redhat.com>
Date: Thu Aug 15 17:43:18 2024 +0100
gdb: fixes for code_breakpoint::disabled_by_cond logic
I spotted that the code_breakpoint::disabled_by_cond flag doesn't work
how I'd expect it too. The flag appears to be "sticky" in some
situations; once a code_breakpoint::disabled_by_cond flag is marked
true, then, in some cases the flag wont automatically become false
again, even when you'd think it should.
The problem is in update_breakpoint_locations. In this function,
which is called as a worker of code_breakpoint::re_set, GDB computes a
new set of locations for a breakpoint, the new locations are then
installed into the breakpoint.
However, before installing the new locations GDB attempts to copy the
bp_location::enabled and bp_location::disabled_by_cond flag from the
old locations into the new locations.
The reason for copying the ::enabled flag makes sense. This flag is
controlled by the user. When we create the new locations if GDB can
see that a new location is equivalent to one of the old locations, and
if the old location was disabled by the user, then the new location
should also be disabled.
However, I think the logic behind copying the ::disabled_by_cond flag
is wrong. The disabled_by_cond flag is controlled by GDB and should
toggle automatically. If the condition string can be parsed then the
flag should be false (b/p enabled), if the condition string can't be
parsed then the flag should be true (b/p disabled).
As we always parse the condition string in update_breakpoint_locations
before we try to copy the ::enabled flag value then the
::disabled_by_cond flag should already be correct, there's no need to
copy over the ::disabled_by_cond value from the old location.
As a concrete example, consider a b/p placed within the main
executable, but with a condition that depends on a variable within a
shared library.
When the b/p is initially created the b/p will be disabled as the
condition string will be invalid (the shared library variable isn't
available yet).
When the inferior starts the shared library is loaded and the
condition variable becomes available to GDB. When the shared library
is loaded breakpoint_re_set is called which (eventually) calls
update_breakpoint_locations.
A new location is computed for the breakpoint and the condition string
is parsed. As the shared library variable is now know the expression
parses correctly and ::disabled_by_cond is left false for the new
location.
But currently GDB spots that the new location is at the same address
as the old location and copies disabled_by_cond over from the old
location, which marks the b/p location as disabled. This is not what
I would expect.
The solution is simple, don't copy over disabled_by_cond.
While writing a test I found another problem though. The
disabled_by_cond flag doesn't get set true when it should! This is
the exact opposite of the above.
The problem here is in solib_add which is (despite the name) called
whenever the shared library set changes, including when a shared
library is unloaded.
Imagine an executable that uses dlopen/dlclose to load a shared
library. Given an example of a b/p in the main executable that has a
condition that uses a variable from our shared library, a library
which might be unloaded with dlclose.
My expectation is that, when the library is unloaded, GDB will
automatically mark the breakpoint as disabled_by_cond, however, this
was not happening.
The problem is that in solib_add we only call breakpoint_re_set when
shared libraries are added, not when shared libraries are removed.
The solution I think is to just call breakpoint_re_set in both cases,
now the disabled_by_cond flag is updated as I'd expect.
Unfortunately, making this change causes a regression when running:
make check-gdb \
TESTS="gdb.trace/change-loc.exp" \
RUNTESTFLAGS="--target_board=native-gdbserver"
This test unloads a shared library and expects breakpoints within the
shared library to enter the PENDING state (because the bp_location's
shlib_disabled flag will be set). However, the new call to
breakpoint_re_set means that this is no longer the case.
The breakpoint_re_set call means that update_breakpoint_locations is
called, which then checks if all locations for a breakpoint are
pending or not. In this test not all locations are pending, and so
GDB recalculates the locations of each breakpoint, this means that
pending locations are discarded.
There is a but report PR gdb/32404 which mentions the problems with
shlib_disabled pending breakpoints, and how they are prone to being
randomly deleted if the user can cause GDB to trigger a call to
breakpoint_re_set. This patch just adds another call to
breakpoint_re_set, which triggers this bug in this one test case.
For now I have marked this test as KFAIL. I do plan to try and
address the pending (shlib_disabled) breakpoint problem in the future,
but I'm not sure when that will be right now.
There are, of course, tests to cover all these cases.
During review I was pointed at bug PR gdb/32079 as something that this
commit might fix, or help in fixing.
And this commit is part of the fix for that bug, but is not the
complete solution. However, the remaining parts of the fix for that
bug are not really related to the content of this commit.
The problem in PR gdb/32079 is that the inferior maps multiple copies
of libc in different linker namespaces using dlmopen (actually libc is
loaded as a consequence of loading some other library into a different
namespace, but that's just a detail). The user then uses a 'next'
command to move the inferior forward.
GDB sets up internal breakpoints on the longjmp symbols, of which
there are multiple copies (there is a copy in every loaded libc).
However, the 'next' command is, in the problem case, stepping over a
dlclose call which unloads one of the loaded libc libraries.
In current HEAD GDB in solib_add we fail to call breakpoint_re_set()
when the library is unloaded; breakpoint_re_set() would delete and
then recreate the longjmp breakpoints. As breakpoint_re_set() is not
called GDB thinks that the the longjmp breakpoint in the now unloaded
libc still exists, and is still inserted.
When the inferior stops after the 'next' GDB tries to delete and
remove the longjmp breakpoint which fails as the libc in which the
breakpoint was inserted is no longer mapped in.
When the user tries to 'next' again GDB tries to re-insert the still
existing longjmp breakpoint which again fails as the memory in which
the b/p should be inserted is no longer part of the inferior memory
space.
This commit helps a little. Now when the libc library is unmapped GDB
does call breakpoint_re_set(). This deletes the longjmp breakpoints
including the one in the unmapped library, then, when we try to
recreate the longjmp breakpoints (at the end of breakpoint_re_set) we
don't create a b/p in the now unmapped copy of libc.
However GDB does still think that the deleted breakpoint is inserted.
The breakpoint location remains in GDB's data structures until the
next time the inferior stops, at which point GDB tries to remove the
breakpoint .... and fails.
However, as the b/p is now deleted, when the user tries to 'next' GDB
no longer tries to re-insert the b/p, and so one of the problems
reported in PR gdb/32079 is resolved.
I'll fix the remaining issues from PR gdb/32079 in a later commit in
this series.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32079
Tested-By: Hannes Domani <ssbssa@yahoo.de>
Approved-By: Tom Tromey <tom@tromey.com>
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects
2024-08-13 13:16 [Bug breakpoints/32079] New: Can't insert internal breakpoints after inferior dlclose some share objects blarsen at redhat dot com
` (6 preceding siblings ...)
2025-02-24 11:02 ` cvs-commit at gcc dot gnu.org
@ 2025-02-24 11:02 ` cvs-commit at gcc dot gnu.org
2025-02-24 11:03 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2025-02-24 11:02 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=32079
--- Comment #7 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0e9794f1f27529ccc50549434aa68007c64a88e2
commit 0e9794f1f27529ccc50549434aa68007c64a88e2
Author: Andrew Burgess <aburgess@redhat.com>
Date: Thu Dec 5 17:17:38 2024 +0000
gdb: don't clear inserted flag in disable_breakpoints_in_unloaded_shlib
This commit removes the clearing of bp_location::inserted from
disable_breakpoints_in_unloaded_shlib, my claim is that this call is
not needed (any more), and with the next commit, this line actually
causes some problems.
The disable_breakpoints_in_unloaded_shlib function was added back in
2004 with commit 84acb35a5a97c, and from this first version the
function cleared the bp_location::inserted flag. The motivation for
this is that the shared library might have already been unmapped, in
which case, a later attempt to remove the location could fail.
In 2013 a similar function disable_breakpoints_in_freed_objfile was
added. This function also cleared bp_location::inserted for similar
reasons. This code was added in commit:
commit 63644780babdca3f40e1978a236b6cd78473c91b
Date: Tue Mar 12 11:10:18 2013 +0100
New remove-symbol-file command.
Then in 2014 the clearing of bp_location::inserted was removed from
disable_breakpoints_in_freed_objfile in the commit:
commit 08351840eabb44799e3d01026610420758f4fa40
Date: Tue Apr 22 23:19:19 2014 +0100
Stale breakpoint instructions, spurious SIGTRAPS.
The reason that clearing the ::inserted flag was removed in this
commit is that if the disable_breakpoints_in_freed_objfile function
was called when the b/p were actually inserted, and the memory for the
associated objfile wasn't actually unmapped, then we could end up
leaving breakpoints inserted into the inferior, which leads to
spurious SIGTRAPs.
In the next commit I'll change disable_breakpoints_in_unloaded_shlib
so that all breakpoints, not just user breakpoints, will be
disabled (via shlib_disabled) when a shared library is unloaded. This
addresses PR gdb/32079, see the next commit for a fuller justification
for this change.
The problem is that when I tested the next commit I ran into some
regressions from the gdb.base/nostdlib.exp test when run on an AArch64
GNU/Linux system where executables are compiled as PIE by default.
This test compiles a simple binary with the -nostdlib flag.
What happens is this:
- The executable is compiled as PIE, this means that we get a
dynamically linked executable, the dynamic linker is used to
perform the PIE relocation, but the executable uses no other
shared libraries.
- When GDB starts the inferior, initially the dynamic linker is
discovered as a shared library being used by the application, GDB
loads in the library and its debug symbols, placing the internal
"shlib event" breakpoints so that future shared library events can
be tracked.
- For the target I tested on systemtap probes were not used, instead
GDB fell back to the old style even breakpoint.
- As the inferior progresses, after the PIE relocation has been
performed, the dynamic linker performs some house keeping on the
list of shared libraries being used by the application. During
this process the dynamic linker is removed from the list of shared
libraries being used by the inferior, this causes GDB see a shared
library event, which GDB understands to mean that it should unload
the dynamic linker from the inferior.
I spoke with the glibc engineers at RH, and the feeling is that
this is likely a bug (it's still being investigated). But I don't
think it really matters if this is a bug or not. There are
versions of glibc in the wild that have this behaviour, so GDB
should (if the cost is not too great) be updated to handle this.
Obviously after removing the dynamic linker from the list of
shared libraries, the dynamic linker is not actually unmapped,
that would not be possible, it's the dynamic linker that does the
unmapping, so the dynamic linker is left mapped into the
inferior's address space.
- With the next patch in place all breakpoints (user and internal)
within the dynamic linker are disabled (shlib_disabled) and
currently marked as not inserted (bp_location::inserted flag is
cleared).
- Having processed the shared library event GDB then resumes the
inferior. As the shared library event is not a full stop of the
inferior (i.e. we don't remove all breakpoints before handling the
event), all of the breakpoints in the dynamic linker are still
inserted, but are now marked as not-inserted.
- GDB then resumes the inferior and immediately hits the breakpoint
that is still inserted. As GDB thinks this breakpoint is not
inserted, this is reported to the user as a SIGTRAP.
The fix I think is just to not clear the bp_location::inserted flag in
disable_breakpoints_in_unloaded_shlib. This will leave the breakpoint
as inserted in the case above. GDB will now be able to successfully
resume the inferior after the shared library event (knowing there is a
breakpoint inserted GDB will step over it and continue as expected).
The next time the inferior performs a full stop the now shlib_disabled
breakpoint will be removed from the inferior we would want.
For the usual case, where a shared library is being unloaded due to
say a dlclose, the breakpoints in the library will be marked as
disabled, but will be left inserted. The next time remove_breakpoints
is called GDB will try to remove those breakpoint locations. If the
removal fails, as the breakpoint is marked shlib_disabled, GDB will
hide the error message from the user and just assume that the shared
library has been unmapped. This functionality was first added in 2008
in commit 879d1e6b4674bc8.
There are two aspects to testing this change. First whether no
clearing the ::inserted flag causes general problems. That is tested
by running the full testsuite (I see no regressions).
Then there is the specific problem that caused me to make this
change. That issue only occurs on AArch64, with GNU/Linux using
glibc, when the executable is compiled as PIE, and doesn't use any
shared libraries other than the dynamic linker (which can be the
gdb.base/nostdlib.exp test if run on the right system). What I don't
know is how to recreate this setup in a more general form.
We can't use add-symbol-file/remove-symbol-file as that passes through
disable_breakpoints_in_freed_objfile instead, which the ::installed
flag is already not adjusted.
Also the bug doesn't trigger on x86 targets due to code in
handle_signal_stop which sees the inserted breakpoint, and decides
this must be a breakpoint that actually exists in the program, and
then because gdbarch_decr_pc_after_break returns non-zero for x86, GDB
steps the inferior past the breakpoint. This is the big difference
from AArch64 where gdbarch_decr_pc_after_break returns zero, and so
the inferior gets stuck hitting the unexpectedly inserted breakpoint.
Approved-By: Tom Tromey <tom@tromey.com>
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects
2024-08-13 13:16 [Bug breakpoints/32079] New: Can't insert internal breakpoints after inferior dlclose some share objects blarsen at redhat dot com
` (7 preceding siblings ...)
2025-02-24 11:02 ` cvs-commit at gcc dot gnu.org
@ 2025-02-24 11:03 ` cvs-commit at gcc dot gnu.org
2025-02-24 16:35 ` aburgess at redhat dot com
2025-02-24 17:08 ` ssbssa at sourceware dot org
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2025-02-24 11:03 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=32079
--- Comment #8 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4f578099f946b3e9f34a4e2de3ef62012a437fd1
commit 4f578099f946b3e9f34a4e2de3ef62012a437fd1
Author: Andrew Burgess <aburgess@redhat.com>
Date: Wed Aug 28 17:00:37 2024 +0100
gdb: disable internal b/p when a solib is unloaded
Bug PR gdb/32079 highlights an issue where GDB will try to remove a
breakpoint for a shared library that has been unloaded. This will
trigger an error from GDB like:
(gdb) next
61 dlclose (handle[dl]);
(gdb) next
warning: error removing breakpoint 0 at 0x7ffff78169b9
warning: error removing breakpoint 0 at 0x7ffff7730b57
warning: error removing breakpoint 0 at 0x7ffff7730ad3
54 for (dl = 0; dl < 4; ++dl)
(gdb)
What happens is that as the inferior steps over the dlclose() call,
GDB notices that the library has been unloaded and calls
disable_breakpoints_in_unloaded_shlib. However, this function only
operates on user breakpoints and tracepoints.
In the example above what is happening is that the test loads multiple
copies of libc into different linker namespsaces. When we 'next' over
the dlclose call one of the copies of libc is unloaded. As GDB placed
longjmp master breakpoints within the copy of libc that was just
unloaded, the warnings we see are GDB trying (and failing) to remove
these breakpoints.
I think the solution is for disable_breakpoints_in_unloaded_shlib to
handle all breakpoints, even internal ones like the longjmp master
breakpoints.
If we do this then the breakpoint will be marked as shlib_disabled and
also will be marked as not inserted. Later when we call
breakpoint_re_set() and the longjmp breakpoints are deleted we will no
longer try to remove them.
This solution is inspired by a patch suggested in the bug report:
https://sourceware.org/bugzilla/show_bug.cgi?id=32079#c3
There are some differences with my approach compared to the patch
suggested in the bug. First I have no need to delete the breakpoint
inside disable_breakpoints_in_unloaded_shlib as an earlier patch in
this series arranged for breakpoint_re_set to be called when shared
libraries are removed. Calling breakpoint_re_set will take care of
deleting the breakpoint for us. For details see the earlier commit
titled:
gdb: fixes for code_breakpoint::disabled_by_cond logic
Next, rather than only handling bp_longjmp and bp_longjmp_master, I
allow all breakpoints to be handled. I also only give the warning
about disabling breakpoints for user breakpoints, I don't see the
point of warning the user about internal b/p changes.
With this done the issues in PR gdb/32079 are resolved.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32079
Tested-By: Hannes Domani <ssbssa@yahoo.de>
Approved-By: Tom Tromey <tom@tromey.com>
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects
2024-08-13 13:16 [Bug breakpoints/32079] New: Can't insert internal breakpoints after inferior dlclose some share objects blarsen at redhat dot com
` (8 preceding siblings ...)
2025-02-24 11:03 ` cvs-commit at gcc dot gnu.org
@ 2025-02-24 16:35 ` aburgess at redhat dot com
2025-02-24 17:08 ` ssbssa at sourceware dot org
10 siblings, 0 replies; 12+ messages in thread
From: aburgess at redhat dot com @ 2025-02-24 16:35 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=32079
Andrew Burgess <aburgess at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #9 from Andrew Burgess <aburgess at redhat dot com> ---
I believe this issue is now fixed.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects
2024-08-13 13:16 [Bug breakpoints/32079] New: Can't insert internal breakpoints after inferior dlclose some share objects blarsen at redhat dot com
` (9 preceding siblings ...)
2025-02-24 16:35 ` aburgess at redhat dot com
@ 2025-02-24 17:08 ` ssbssa at sourceware dot org
10 siblings, 0 replies; 12+ messages in thread
From: ssbssa at sourceware dot org @ 2025-02-24 17:08 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=32079
Hannes Domani <ssbssa at sourceware dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |17.1
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 12+ messages in thread