[Bug breakpoints/32079] New: Can't insert internal breakpoints after inferior dlclose some share objects

[Bug breakpoints/32079] New: Can't insert internal breakpoints after inferior dlclose some share objects

[blarsen at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32079

            Bug ID: 32079
           Summary: Can't insert internal breakpoints after inferior
                    dlclose some share objects
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: breakpoints
          Assignee: unassigned at sourceware dot org
          Reporter: blarsen at redhat dot com
  Target Milestone: ---

As I'm trying to debug what I think is an unrelated issue in
gdb.base/dlmopen.exp, I noticed that stepping through the program (using next)
GDB gets into a state where it tries to insert some internal breakpoints, and
so refuses to let me move forward, but I can't see the number of the breakpoint
to delete it.

Here's a simplified session:

```
$ ./gdb testsuite/outputs/gdb.base/dlmopen/dlmopen
(gdb) start
[Thread debugging using libthread_db enabled]                                   
Using host libthread_db library "/lib64/libthread_db.so.1".                     

Temporary breakpoint 1, main ()                                                 
    at
/home/gwenthekween/Documents/upstream-build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/dlmopen
.c:36
36        handle[0] = dlmopen (LM_ID_NEWLM, DSO1_NAME, RTLD_LAZY | RTLD_LOCAL);
(gdb) n
Python Exception <class 'AttributeError'>: module 'gdb' has no attribute
'_handle_missing_debuginfo'
Python Exception <class 'AttributeError'>: module 'gdb' has no attribute
'_handle_missing_debuginfo'
37        assert (handle[0] != NULL);
(gdb) print wait_for_gdb  = 0
$1 = 0
(gdb) handle SIGALRM ignore
Signal        Stop      Print   Pass to program Description
SIGALRM       No        No      No              Alarm clock
(gdb) next

<snip. removing unimportant "next"s>

54        for (dl = 0; dl < 4; ++dl)                     
(gdb)                                                    
56            fun = dlsym (handle[dl], "inc");           
(gdb)                                                    
57            assert (fun != NULL);                      
(gdb)                                                    
59            fun (42);                                  
(gdb)                                                    
61            dlclose (handle[dl]);                      
(gdb)                                                    
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)                                                    
Warning:                                                 
Cannot insert breakpoint 0.                              
Cannot access memory at address 0x7ffff7730ad3           
Cannot insert breakpoint 0.                              
Cannot access memory at address 0x7ffff7730b57           
Cannot insert breakpoint 0.                              
Cannot access memory at address 0x7ffff78169b9           

Command aborted.                                         
(gdb) p dl                                               
$2 = 2                                                   
(gdb) info break                                         
No breakpoints, watchpoints, tracepoints, or catchpoints.
(gdb) disas /m                           
Dump of assembler code for function main:

<snip unimportant disassembly>

54        for (dl = 0; dl < 4; ++dl)
   0x00000000004012bc <+294>:   movl   $0x0,-0x4(%rbp)
   0x00000000004012c3 <+301>:   jmp    0x401321 <main+395>
=> 0x000000000040131d <+391>:   addl   $0x1,-0x4(%rbp)
   0x0000000000401321 <+395>:   cmpl   $0x3,-0x4(%rbp)
   0x0000000000401325 <+399>:   jle    0x4012c5 <main+303>

<snip disassembly continues>

(gdb)
```

So, this happened after the last dlmopen-lib.1.so was dlclose'd, we are no
longer able to step.

If I set a breakpoint after the loop and continue over it, the issue doesn't
occur, so it seems to be related to internal "next" breakpoints in some way

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects

[ssbssa at sourceware dot org]

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.

[Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects

[blarsen at redhat dot com]

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.

[Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects

[ssbssa at sourceware dot org]

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.

[Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects

[woodard at redhat dot com]

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.

[Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects

[tromey at sourceware dot org]

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.

[Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects

[aburgess at redhat dot com]

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.

[Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects

[cvs-commit at gcc dot gnu.org]

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.

[Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects

[cvs-commit at gcc dot gnu.org]

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.

[Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects

[cvs-commit at gcc dot gnu.org]

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.

[Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects

[aburgess at redhat dot com]

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.

[Bug breakpoints/32079] Can't insert internal breakpoints after inferior dlclose some share objects

[ssbssa at sourceware dot org]

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.