Summary: | gdb.Breakpoint.stop calling gdb.parse_and_eval("(int) $rax") + Ctrl^C crashes GDB (assertion fail) | ||
---|---|---|---|
Product: | gdb | Reporter: | Kevin Pouget <kevin.pouget> |
Component: | python | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | tromey |
Priority: | P2 | ||
Version: | unknown | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Attachments: | Backtrace of the failing assertion |
This stack trace shows an exception being re-thrown. It would be interesting to see where the exception was originally thrown. This might be a little difficult to dig up, though. It would also be nice to see the exception being thrown. Maybe this would let us find the thrower. Another thing that would be worth knowing is which sniffer is being called in frame_unwind_find_by_frame. |
Created attachment 6552 [details] Backtrace of the failing assertion In gdb.Breakpoint.stop callback, the script reads a register value with gdb.parse_and_eval("(int) $rax"). The callback always returns False, so GDB never actually gives the control back to the CLI. Sometimes (certainly a matter of timing), when I hit Ctrl^C, GDB crashes (a failing assertion) with the backtrace in the attachment. There is no other problem with the script.