[Bug breakpoints/19548] New: breakpoint re-set inserts breakpoints when it shouldn't

["palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

            Bug ID: 19548
           Summary: breakpoint re-set inserts breakpoints when it
                    shouldn't
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: breakpoints
          Assignee: unassigned at sourceware dot org
          Reporter: palves at redhat dot com
  Target Milestone: ---

(split out from Bug 19503)

Say we have two inferiors, and a breakpoint that has a location spec matches in
both inferiors.  

As example, I'm using gdb itself:

(top-gdb) info inferiors 
  Num  Description       Executable        
  1    <null>            /home/pedro/gdb/mygit/build/gdb/gdb 
* 2    <null>            /home/pedro/gdb/mygit/build/gdb/gdb 

(top-gdb) info breakpoints
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <MULTIPLE>         
1.1                         y     0x00000000007b9804 in internal_error at
/home/pedro/gdb/mygit/src/gdb/common/errors.c:54 inf 1
1.2                         y     0x00000000007b9804 in internal_error at
/home/pedro/gdb/mygit/src/gdb/common/errors.c:54 inf 2
2       breakpoint     keep y   <MULTIPLE>         
        silent
        return
2.1                         y     0x0000000000510890 in info_command at
/home/pedro/gdb/mygit/src/gdb/cli/cli-cmds.c:218 inf 1
2.2                         y     0x0000000000510890 in info_command at
/home/pedro/gdb/mygit/src/gdb/cli/cli-cmds.c:218 inf 2
(gdb)

Now, say, inferior 2 execs (I've hacked a gdb command that execs dash for
demonstration purposes).  We may see breakpoint re-set failures:

(top-gdb) inferior 2
(top-gdb) run
...
(gdb) maint exec-dash
process 5461 is executing new program: /usr/bin/dash
Error in re-setting breakpoint 1: Warning:
Cannot insert breakpoint 2.
Cannot access memory at address 0x510890 (Thread 2.1)

gdb is wrongly trying to insert a breakpoint that was originally set on
inferior 2, before the exec, on inferior 2's new fresh set of memory pages,
after the exec, even though the breakpoint's symbol and address doesn't make
sense for the post-exec program (dash).  On my system's dash, (x86_64 F20),
that address is not mapped in:

$ gdb /bin/dash
...
(gdb) start
...
(gdb) info proc mappings
          Start Addr           End Addr       Size     Offset objfile
            0x400000           0x41a000    0x1a000        0x0 /usr/bin/dash
            0x619000           0x61a000     0x1000    0x19000 /usr/bin/dash
            0x61a000           0x61b000     0x1000    0x1a000 /usr/bin/dash
            0x61b000           0x61e000     0x3000        0x0 [heap]


And we may be trying to remove other breakpoints and not seeing any warning
just because the bp address is mapped.  That'd be very bad, as it means we'd be
poking the wrong instruction at the wrong address...

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