Bug 14391 - gdb.Breakpoint.stop calling gdb.parse_and_eval("(int) $rax") + Ctrl^C crashes GDB (assertion fail)
Summary: gdb.Breakpoint.stop calling gdb.parse_and_eval("(int) $rax") + Ctrl^C crashes...
Status: RESOLVED DUPLICATE of bug 14100
Alias: None
Product: gdb
Classification: Unclassified
Component: python (show other bugs)
Version: unknown
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-24 14:22 UTC by Kevin Pouget
Modified: 2012-08-02 13:37 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:

Attachments
Backtrace of the failing assertion (1.73 KB, text/plain)
2012-07-24 14:22 UTC, Kevin Pouget 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Pouget 2012-07-24 14:22:07 UTC 
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.
Comment 1 Tom Tromey 2012-07-31 19:18:16 UTC 
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.
Comment 2 Tom Tromey 2012-08-02 13:37:49 UTC 
This turns out to be a duplicate.

*** This bug has been marked as a duplicate of bug 14100 ***