py-finishbreakpoint.exp does this: gdb_test "python print (finishbp_default.hit_count)" "1.*" "check finishBP on default frame has been hit" It is trying to check the hit count of this breakpoint. However, the actual output is: python print (finishbp_default.hit_count) Traceback (most recent call last): File "<string>", line 1, in <module> RuntimeError: Breakpoint 3 is invalid. Error while executing Python code. ... which matches by mistake. This came up in a patch series I'm working on. I plan to kfail this but not close this bug; I think this probably is a real problem of some sort.
(In reply to Tom Tromey from comment #0) > py-finishbreakpoint.exp does this: > > gdb_test "python print (finishbp_default.hit_count)" "1.*" "check > finishBP on default frame has been hit" > > It is trying to check the hit count of this breakpoint. > However, the actual output is: > > python print (finishbp_default.hit_count) > Traceback (most recent call last): > File "<string>", line 1, in <module> > RuntimeError: Breakpoint 3 is invalid. > Error while executing Python code. > > > ... which matches by mistake. > This came up in a patch series I'm working on. > > I plan to kfail this but not close this bug; I think > this probably is a real problem of some sort. I think this may be the behaviour specified here ( https://sourceware.org/gdb/current/onlinedocs/gdb.html/Breakpoints-In-Python.html ): ... The optional temporary argument makes the breakpoint a temporary breakpoint. Temporary breakpoints are deleted after they have been hit. Any further access to the Python breakpoint after it has been hit will result in a runtime error (as that breakpoint has now been automatically deleted). ... So AFAIU, this happens: - finish breakpoints 3 and 4 are set at the same location - a continue hits both finish breakpoints - the hit_count is not available in either breakpoint, as per the doc, because both temporary breakpoints have been deleted. - the return_value is available in both finish breakpoints, because it doesn't rely on accessing the underlying python breakpoint I think the test-case can be updated to accept the current behaviour, or we can even remove the hit_count test.
(In reply to Tom de Vries from comment #1) > (In reply to Tom Tromey from comment #0) > > py-finishbreakpoint.exp does this: > > > > gdb_test "python print (finishbp_default.hit_count)" "1.*" "check > > finishBP on default frame has been hit" > > > > It is trying to check the hit count of this breakpoint. > > However, the actual output is: > > > > python print (finishbp_default.hit_count) > > Traceback (most recent call last): > > File "<string>", line 1, in <module> > > RuntimeError: Breakpoint 3 is invalid. > > Error while executing Python code. > > > > > > ... which matches by mistake. > > This came up in a patch series I'm working on. > > > > I plan to kfail this but not close this bug; I think > > this probably is a real problem of some sort. > > I think this may be the behaviour specified here ( > https://sourceware.org/gdb/current/onlinedocs/gdb.html/Breakpoints-In-Python. > html ): > ... > The optional temporary argument makes the breakpoint a temporary breakpoint. > Temporary breakpoints are deleted after they have been hit. Any further > access to the Python breakpoint after it has been hit will result in a > runtime error (as that breakpoint has now been automatically deleted). > ... > > So AFAIU, this happens: > - finish breakpoints 3 and 4 are set at the same location > - a continue hits both finish breakpoints > - the hit_count is not available in either breakpoint, as per the doc, > because > both temporary breakpoints have been deleted. > - the return_value is available in both finish breakpoints, because it > doesn't > rely on accessing the underlying python breakpoint > > I think the test-case can be updated to accept the current behaviour, or we > can even remove the hit_count test. I'll write a patch to this effect.
(In reply to Tom de Vries from comment #2) > I'll write a patch to this effect. https://sourceware.org/pipermail/gdb-patches/2024-February/206853.html
The master branch has been updated by Tom de Vries <vries@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=cfb9cb1afd93dc71ea94ec7c7d9bfc0e43ace0bc commit cfb9cb1afd93dc71ea94ec7c7d9bfc0e43ace0bc Author: Tom de Vries <tdevries@suse.de> Date: Tue Feb 27 16:18:32 2024 +0100 [gdb/testsuite] Fix test in gdb.python/py-finish-breakpoint.exp With test-case gdb.python/py-finish-breakpoint.exp, we run into: ... (gdb) python print (finishbp_default.hit_count) Traceback (most recent call last): File "<string>", line 1, in <module> RuntimeError: Breakpoint 3 is invalid. Error while executing Python code. (gdb) PASS: gdb.python/py-finish-breakpoint.exp: normal conditions: \ check finishBP on default frame has been hit ... The test producing the pass is: ... gdb_test "python print (finishbp_default.hit_count)" "1.*" \ "check finishBP on default frame has been hit" ... so the pass is produced because the 1 in "line 1" matches "1.*". Temporary breakpoints are removed when hit, and consequently accessing the hit_count attribute of a temporary python breakpoint (gdb.Breakpoint class) is not possible, and as per spec we get a RuntimeError. So the RuntimeError is correct, and not specific to finish breakpoints. The test presumably attempts to match: ... (gdb) python print (finishbp_default.hit_count) 1 ... but most likely this output was never produced by any gdb version. Fix this by checking whether the finishbp_default breakpoint has hit by checking that finishbp_default.is_valid() is False. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR testsuite/31391 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31391
Fixed.