* [PATCH] Fix use of a dangling pointer for Python breakpoint objects @ 2016-06-21 10:40 Pierre-Marie de Rodat 2016-06-23 16:15 ` Pedro Alves 0 siblings, 1 reply; 7+ messages in thread From: Pierre-Marie de Rodat @ 2016-06-21 10:40 UTC (permalink / raw) To: gdb-patches; +Cc: Pierre-Marie de Rodat Hello, When a Python script tries to create a breakpoint but fails to do so, gdb.Breakpoint.__init__ raises an exception and the breakpoint does not exist anymore in the Python interpreter. However, GDB still keeps a reference to the Python object to be used for a later hook, which is wrong. This commit adds the necessary cleanup code so that there is no stale reference to this Python object. It also adds a new testcase to reproduce the bug and check the fix. There is no regression on my x86_64-linux machine: ok to push? Thank you in advance! 2016-06-21 Pierre-Marie de Rodat <derodat@adacore.com> gdb/ * python/py-breakpoint.c (bppy_init): Clear bppy_pending_object when there is an error during the breakpoint creation. gdb/testsuite * gdb.python/py-breakpoint2.c, gdb.python/py-breakpoint2.exp, gdb.python/py-breakpoint2.py: New testcase. --- gdb/python/py-breakpoint.c | 1 + gdb/testsuite/gdb.python/py-breakpoint2.c | 22 +++++++++++++++++++ gdb/testsuite/gdb.python/py-breakpoint2.exp | 34 +++++++++++++++++++++++++++++ gdb/testsuite/gdb.python/py-breakpoint2.py | 31 ++++++++++++++++++++++++++ 4 files changed, 88 insertions(+) create mode 100644 gdb/testsuite/gdb.python/py-breakpoint2.c create mode 100644 gdb/testsuite/gdb.python/py-breakpoint2.exp create mode 100644 gdb/testsuite/gdb.python/py-breakpoint2.py diff --git a/gdb/python/py-breakpoint.c b/gdb/python/py-breakpoint.c index ed9cae6..5918bcc 100644 --- a/gdb/python/py-breakpoint.c +++ b/gdb/python/py-breakpoint.c @@ -705,6 +705,7 @@ bppy_init (PyObject *self, PyObject *args, PyObject *kwargs) } CATCH (except, RETURN_MASK_ALL) { + bppy_pending_object = NULL; PyErr_Format (except.reason == RETURN_QUIT ? PyExc_KeyboardInterrupt : PyExc_RuntimeError, "%s", except.message); diff --git a/gdb/testsuite/gdb.python/py-breakpoint2.c b/gdb/testsuite/gdb.python/py-breakpoint2.c new file mode 100644 index 0000000..0a535a4 --- /dev/null +++ b/gdb/testsuite/gdb.python/py-breakpoint2.c @@ -0,0 +1,22 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2016 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see <http://www.gnu.org/licenses/>. */ + +int +main (void) +{ + return 0; +} diff --git a/gdb/testsuite/gdb.python/py-breakpoint2.exp b/gdb/testsuite/gdb.python/py-breakpoint2.exp new file mode 100644 index 0000000..0a3a7ca --- /dev/null +++ b/gdb/testsuite/gdb.python/py-breakpoint2.exp @@ -0,0 +1,34 @@ +# Copyright (C) 2016 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +# This file is part of the GDB testsuite. It tests the mechanism +# exposing breakpoints to Python. + +load_lib gdb-python.exp + +standard_testfile + +if { [prepare_for_testing ${testfile}.exp ${testfile} ${srcfile}] } { + return -1 +} + +# Skip all tests if Python scripting is not enabled. +if { [skip_python_tests] } { continue } + +gdb_test "source py-breakpoint2.py" + +# The following used to trigger an internal error because of a dangling +# reference to a Python breakpoint object. +gdb_test "start" diff --git a/gdb/testsuite/gdb.python/py-breakpoint2.py b/gdb/testsuite/gdb.python/py-breakpoint2.py new file mode 100644 index 0000000..9e0a379 --- /dev/null +++ b/gdb/testsuite/gdb.python/py-breakpoint2.py @@ -0,0 +1,31 @@ +# Copyright (C) 2016 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +# This file is part of the GDB testsuite. It tests the mechanism +# exposing breakpoints to Python. + +import gdb + +bp1 = gdb.Breakpoint('main', gdb.BP_BREAKPOINT) + +# The following will create a breakpoint whose construction will abort (there +# is no such symbol), so GDB should not keep a reference to the corresponding +# Python object. +try: + bp2 = gdb.Breakpoint('does_not_exist', gdb.BP_WATCHPOINT) +except RuntimeError: + pass +else: + assert False -- 2.8.3 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Fix use of a dangling pointer for Python breakpoint objects 2016-06-21 10:40 [PATCH] Fix use of a dangling pointer for Python breakpoint objects Pierre-Marie de Rodat @ 2016-06-23 16:15 ` Pedro Alves 2016-06-24 9:21 ` Pierre-Marie de Rodat 0 siblings, 1 reply; 7+ messages in thread From: Pedro Alves @ 2016-06-23 16:15 UTC (permalink / raw) To: Pierre-Marie de Rodat, gdb-patches On 06/21/2016 11:40 AM, Pierre-Marie de Rodat wrote: > Hello, > > When a Python script tries to create a breakpoint but fails to do so, > gdb.Breakpoint.__init__ raises an exception and the breakpoint does not > exist anymore in the Python interpreter. However, GDB still keeps a > reference to the Python object to be used for a later hook, which is > wrong. Urgh, this code is ugly. So the problem is that the next time gdbpy_breakpoint_created is called, for some other breakpoint, we'll dereference the dangling pointer then, correct? > + > +# Skip all tests if Python scripting is not enabled. > +if { [skip_python_tests] } { continue } > + > +gdb_test "source py-breakpoint2.py" > + > +# The following used to trigger an internal error because of a dangling > +# reference to a Python breakpoint object. > +gdb_test "start" "start" doesn't work with "target remote" testing. Try: $ make check \ RUNTESTFLAGS="--target_board=native-gdbserver" \ TESTS="gdb.python/py-breakpoint2.exp" Can we instead run to main first, and then source the python script? > + > +bp1 = gdb.Breakpoint('main', gdb.BP_BREAKPOINT) I don't understand the idea behind creating this breakpoint before the failing watchpoint one. > + > +# The following will create a breakpoint whose construction will abort (there > +# is no such symbol), so GDB should not keep a reference to the corresponding > +# Python object. > +try: > + bp2 = gdb.Breakpoint('does_not_exist', gdb.BP_WATCHPOINT) > +except RuntimeError: > + pass > +else: > + assert False Wouldn't it better to create a breakpoint after the one that failed, explicitly? Either in python, or perhaps simpler, a regular command line breakpoint directly in the .exp file. Ah, I think I see -- I guess the test is relying on "start" creating a magic breakpoint at "main", and that one being the one that dereferences the dangling pointer. But, see above about remote testing. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Fix use of a dangling pointer for Python breakpoint objects 2016-06-23 16:15 ` Pedro Alves @ 2016-06-24 9:21 ` Pierre-Marie de Rodat 2016-06-24 16:41 ` Pedro Alves 0 siblings, 1 reply; 7+ messages in thread From: Pierre-Marie de Rodat @ 2016-06-24 9:21 UTC (permalink / raw) To: Pedro Alves, gdb-patches [-- Attachment #1: Type: text/plain, Size: 1137 bytes --] Thank you for your review, Pedro! On 06/23/2016 06:14 PM, Pedro Alves wrote: > So the problem is that the next time gdbpy_breakpoint_created > is called, for some other breakpoint, we'll dereference the dangling > pointer then, correct? Exactly. This happens when a second breakpoint is created but not using the Python API, otherwise bppy_pending_object is set to a new Python wrapper before it is reused. > "start" doesn't work with "target remote" testing. Try: > > $ make check \ > RUNTESTFLAGS="--target_board=native-gdbserver" \ > TESTS="gdb.python/py-breakpoint2.exp" > > Can we instead run to main first, and then source the python > script? Ah, I did not know that, thanks. > Wouldn't it better to create a breakpoint after the one > that failed, explicitly? Either in python, or perhaps > simpler, a regular command line breakpoint directly in > the .exp file. Good idea! Iâve reworked the testcase as you said. The bug does not manifest with a crash anymore, though: itâs just that a Python method is called whereas it should not. But it may be a more reliable testcase. -- Pierre-Marie de Rodat [-- Attachment #2: 0001-Fix-use-of-a-dangling-pointer-for-Python-breakpoint-.patch --] [-- Type: text/x-diff, Size: 6539 bytes --] From 4b0b57cd285297f533ef9fc27f28e5da5f8ccd0a Mon Sep 17 00:00:00 2001 From: Pierre-Marie de Rodat <derodat@adacore.com> Date: Tue, 21 Jun 2016 12:32:56 +0200 Subject: [PATCH] Fix use of a dangling pointer for Python breakpoint objects When a Python script tries to create a breakpoint but fails to do so, gdb.Breakpoint.__init__ raises an exception and the breakpoint does not exist anymore in the Python interpreter. However, GDB still keeps a reference to the Python object to be used for a later hook, which is wrong. This commit adds the necessary cleanup code so that there is no stale reference to this Python object. It also adds a new testcase to reproduce the bug and check the fix. 2016-06-24 Pierre-Marie de Rodat <derodat@adacore.com> gdb/ * python/py-breakpoint.c (bppy_init): Clear bppy_pending_object when there is an error during the breakpoint creation. gdb/testsuite * gdb.python/py-breakpoint2.c, gdb.python/py-breakpoint2.exp, gdb.python/py-breakpoint2.py: New testcase. --- gdb/python/py-breakpoint.c | 1 + gdb/testsuite/gdb.python/py-breakpoint2.c | 28 +++++++++++++++ gdb/testsuite/gdb.python/py-breakpoint2.exp | 54 +++++++++++++++++++++++++++++ gdb/testsuite/gdb.python/py-breakpoint2.py | 34 ++++++++++++++++++ 4 files changed, 117 insertions(+) create mode 100644 gdb/testsuite/gdb.python/py-breakpoint2.c create mode 100644 gdb/testsuite/gdb.python/py-breakpoint2.exp create mode 100644 gdb/testsuite/gdb.python/py-breakpoint2.py diff --git a/gdb/python/py-breakpoint.c b/gdb/python/py-breakpoint.c index ed9cae6..5918bcc 100644 --- a/gdb/python/py-breakpoint.c +++ b/gdb/python/py-breakpoint.c @@ -705,6 +705,7 @@ bppy_init (PyObject *self, PyObject *args, PyObject *kwargs) } CATCH (except, RETURN_MASK_ALL) { + bppy_pending_object = NULL; PyErr_Format (except.reason == RETURN_QUIT ? PyExc_KeyboardInterrupt : PyExc_RuntimeError, "%s", except.message); diff --git a/gdb/testsuite/gdb.python/py-breakpoint2.c b/gdb/testsuite/gdb.python/py-breakpoint2.c new file mode 100644 index 0000000..c346bdd --- /dev/null +++ b/gdb/testsuite/gdb.python/py-breakpoint2.c @@ -0,0 +1,28 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2016 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see <http://www.gnu.org/licenses/>. */ + +int +foo (int a) +{ + return a * 2; +} + +int +main (void) +{ + return foo (2); +} diff --git a/gdb/testsuite/gdb.python/py-breakpoint2.exp b/gdb/testsuite/gdb.python/py-breakpoint2.exp new file mode 100644 index 0000000..e835fd8 --- /dev/null +++ b/gdb/testsuite/gdb.python/py-breakpoint2.exp @@ -0,0 +1,54 @@ +# Copyright (C) 2016 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +# This file is part of the GDB testsuite. It tests the mechanism +# exposing breakpoints to Python. + +load_lib gdb-python.exp + +standard_testfile + +if { [prepare_for_testing ${testfile}.exp ${testfile} ${srcfile}] } { + return -1 +} + +# Skip all tests if Python scripting is not enabled. +if { [skip_python_tests] } { continue } + +clean_restart "${testfile}" +if ![runto_main] { + perror "could not run to main" + continue +} + +# The following will create a breakpoint Python wrapper whose construction will +# abort: the requested symbol is not defined. GDB should not keep a reference +# to the wrapper; however it used to... +gdb_test "source py-breakpoint2.py" + +# ... and when it did, as a result, the following breakpoint creation (not +# initiated by the Python API) will re-use the previous Python wrapper... +gdb_test "break foo" + +# ... eventually, triggering this breakpoint will invoke the Python wrapper +# "stop" method for an object that is not supposed to exist. +gdb_test_multiple "continue" "continuing to foo" { + -re ".*MyBP\.stop was invoked\!.*" { + fail "wrong breakpoint Python wrapper involved" + } + -re "Continuing.*Breakpoint 2, foo.*" { + pass "ok" + } +} diff --git a/gdb/testsuite/gdb.python/py-breakpoint2.py b/gdb/testsuite/gdb.python/py-breakpoint2.py new file mode 100644 index 0000000..6cd2ff2 --- /dev/null +++ b/gdb/testsuite/gdb.python/py-breakpoint2.py @@ -0,0 +1,34 @@ +# Copyright (C) 2016 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +# This file is part of the GDB testsuite. It tests the mechanism +# exposing breakpoints to Python. + +import gdb + + +class MyBP(gdb.Breakpoint): + def stop(self): + print('MyBP.stop was invoked!') + # Don't make this breakpoint stop + return False + + +try: + bp = MyBP('does_not_exist', gdb.BP_WATCHPOINT) +except RuntimeError: + pass +else: + assert False -- 2.8.3 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Fix use of a dangling pointer for Python breakpoint objects 2016-06-24 9:21 ` Pierre-Marie de Rodat @ 2016-06-24 16:41 ` Pedro Alves 2016-06-27 9:11 ` Pierre-Marie de Rodat 0 siblings, 1 reply; 7+ messages in thread From: Pedro Alves @ 2016-06-24 16:41 UTC (permalink / raw) To: Pierre-Marie de Rodat, gdb-patches Hi Pierre-Marie, On 06/24/2016 10:21 AM, Pierre-Marie de Rodat wrote: > Good idea! Iâve reworked the testcase as you said. The bug does not > manifest with a crash anymore, though: itâs just that a Python method is > called whereas it should not. But it may be a more reliable testcase. That sounds like undefined behavior, not something we should be relying on. For example, I ran the new test manually under Valgrind now, and it shows: (gdb) b foo Breakpoint 2 at 0x40059d: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.python/py-breakpoint2.c, line 21. ==19710== Invalid write of size 4 ==19710== at 0x4E574E: gdbpy_breakpoint_created(breakpoint*) (py-breakpoint.c:886) ==19710== by 0x66FE02: observer_breakpoint_created_notification_stub(void const*, void const*) (observer.inc:825) ==19710== by 0x66ECA4: generic_observer_notify(observer_list*, void const*) (observer.c:167) ==19710== by 0x66FE97: observer_notify_breakpoint_created(breakpoint*) (observer.inc:850) ==19710== by 0x575471: install_breakpoint(int, breakpoint*, int) (breakpoint.c:8632) ==19710== by 0x576E4E: create_breakpoint_sal(gdbarch*, symtabs_and_lines, event_location*, char*, char*, char*, bptype, bpdisp, int, int, int, breakpoint_ops const*, int, int, int, unsigned int, int) (breakpoint.c:9430) ==19710== by 0x576FAE: create_breakpoints_sal(gdbarch*, linespec_result*, char*, char*, bptype, bpdisp, int, int, int, breakpoint_ops const*, int, int, int, unsigned int) (breakpoint.c:9481) ==19710== by 0x580952: create_breakpoints_sal_default(gdbarch*, linespec_result*, char*, char*, bptype, bpdisp, int, int, int, breakpoint_ops const*, int, int, int, unsigned int) (breakpoint.c:14554) ==19710== by 0x57E65B: bkpt_create_breakpoints_sal(gdbarch*, linespec_result*, char*, char*, bptype, bpdisp, int, int, int, breakpoint_ops const*, int, int, int, unsigned int) (breakpoint.c:13286) ==19710== by 0x577E16: create_breakpoint(gdbarch*, event_location const*, char*, int, char*, int, int, bptype, int, auto_boolean, breakpoint_ops const*, int, int, int, unsigned int) (breakpoint.c:9906) ==19710== by 0x57826A: break_command_1(char*, int, int) (breakpoint.c:10014) ==19710== by 0x5784C7: break_command(char*, int) (breakpoint.c:10080) ==19710== Address 0x13f89208 is 40 bytes inside a block of size 80 free'd ==19710== at 0x4C29CF0: free (vg_replace_malloc.c:530) ==19710== by 0x6350BF6: subtype_dealloc (typeobject.c:1201) ==19710== by 0x63515D0: type_call (typeobject.c:900) ==19710== by 0x62FBDB0: PyObject_Call (abstract.c:2040) ==19710== by 0x63AF4A5: do_call (ceval.c:4495) ==19710== by 0x63AF4A5: call_function (ceval.c:4293) ==19710== by 0x63AF4A5: PyEval_EvalFrameEx (ceval.c:2862) ==19710== by 0x63B46D5: PyEval_EvalCodeEx (ceval.c:3617) ==19710== by 0x63B477A: PyEval_EvalCode (ceval.c:795) ==19710== by 0x63D09F3: run_mod (pythonrun.c:2188) ==19710== by 0x63D2C34: PyRun_FileExFlags (pythonrun.c:2141) ==19710== by 0x63D3CB2: PyRun_SimpleFileExFlags (pythonrun.c:1614) ==19710== by 0x4DF693: python_run_simple_file(_IO_FILE*, char const*) (python.c:379) ==19710== by 0x4E088E: gdbpy_source_script(extension_language_defn const*, _IO_FILE*, char const*) (python.c:901) So it could well still crash, depending on the phase of the moon. > + > +# This file is part of the GDB testsuite. It tests the mechanism > +# exposing breakpoints to Python. I think this comment should be adjusted. > +# The following will create a breakpoint Python wrapper whose construction will > +# abort: the requested symbol is not defined. GDB should not keep a reference > +# to the wrapper; however it used to... > +gdb_test "source py-breakpoint2.py" > + > +# ... and when it did, as a result, the following breakpoint creation (not > +# initiated by the Python API) will re-use the previous Python wrapper... > +gdb_test "break foo" s/will/would reuse/ or s/will/reused/ But I think this would be even better: # ... and when it did, as a result, the following breakpoint creation # (not initiated by the Python API) would dereference the # already-freed Python breakpoint wrapper, resulting in undefined # behavior, sometimes observed as a gdb crash, and other times causing # the next stop to invoke the Python wrapper "stop" method for the # object that is not supposed to exist. > + > +# ... eventually, triggering this breakpoint will invoke the Python wrapper > +# "stop" method for an object that is not supposed to exist. > +gdb_test_multiple "continue" "continuing to foo" { > + -re ".*MyBP\.stop was invoked\!.*" { > + fail "wrong breakpoint Python wrapper involved" > + } > + -re "Continuing.*Breakpoint 2, foo.*" { > + pass "ok" > + } > +} Three things here: - Please make pass/fail messages here the same. - With gdb_test_multiple, you also need to match $gdb_prompt, otherwise you confuse the next test. - No need for leading ".*" in regexes, it's implicit. So write: set test "continuing to foo" gdb_test_multiple "continue" $test { -re "MyBP\.stop was invoked\!.*$gdb_prompt $" { fail $test } -re "Breakpoint 2, foo.*$gdb_prompt $" { pass $test } } > diff --git a/gdb/testsuite/gdb.python/py-breakpoint2.py b/gdb/testsuite/gdb.python/py-breakpoint2.py > new file mode 100644 > index 0000000..6cd2ff2 > --- /dev/null > +++ b/gdb/testsuite/gdb.python/py-breakpoint2.py > @@ -0,0 +1,34 @@ While at it, how about renaming the new files to avoid the meaningless "2"? Maybe py-breakpoint-create-fail.[py|exp|c] ? Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Fix use of a dangling pointer for Python breakpoint objects 2016-06-24 16:41 ` Pedro Alves @ 2016-06-27 9:11 ` Pierre-Marie de Rodat 2016-06-27 10:03 ` Pedro Alves 0 siblings, 1 reply; 7+ messages in thread From: Pierre-Marie de Rodat @ 2016-06-27 9:11 UTC (permalink / raw) To: Pedro Alves, gdb-patches [-- Attachment #1: Type: text/plain, Size: 1226 bytes --] Hi Pedro, On 06/24/2016 06:41 PM, Pedro Alves wrote: > I think this comment should be adjusted. Done. > But I think this would be even better: > > # ... and when it did, as a result, the following breakpoint creation > # (not initiated by the Python API) would dereference the > # already-freed Python breakpoint wrapper, resulting in undefined > # behavior, sometimes observed as a gdb crash, and other times causing > # the next stop to invoke the Python wrapper "stop" method for the > # object that is not supposed to exist. Yours is definitely better: done! > Three things here: > > - Please make pass/fail messages here the same. > > - With gdb_test_multiple, you also need to match $gdb_prompt, > otherwise you confuse the next test. > > - No need for leading ".*" in regexes, it's implicit. Done. > While at it, how about renaming the new files to avoid > the meaningless "2"? > > Maybe py-breakpoint-create-fail.[py|exp|c] ? Done as well. Thank you for your help! Iâm not familiar with the testsuite so I had a hard time analyzing how other testcases do and investigating why my testcase did not work⦠Anyway, thank you for the rationale! Updated patch is attached. -- Pierre-Marie de Rodat [-- Attachment #2: 0001-Fix-use-of-a-dangling-pointer-for-Python-breakpoint-.patch --] [-- Type: text/x-diff, Size: 6849 bytes --] From 8e8bf8cfd8c07b65cdde21066cf4a25b63b3fec5 Mon Sep 17 00:00:00 2001 From: Pierre-Marie de Rodat <derodat@adacore.com> Date: Tue, 21 Jun 2016 12:32:56 +0200 Subject: [PATCH] Fix use of a dangling pointer for Python breakpoint objects When a Python script tries to create a breakpoint but fails to do so, gdb.Breakpoint.__init__ raises an exception and the breakpoint does not exist anymore in the Python interpreter. However, GDB still keeps a reference to the Python object to be used for a later hook, which is wrong. This commit adds the necessary cleanup code so that there is no stale reference to this Python object. It also adds a new testcase to reproduce the bug and check the fix. 2016-06-24 Pierre-Marie de Rodat <derodat@adacore.com> gdb/ * python/py-breakpoint.c (bppy_init): Clear bppy_pending_object when there is an error during the breakpoint creation. gdb/testsuite * gdb.python/py-breakpoint-create-fail.c, gdb.python/py-breakpoint-create-fail.exp, gdb.python/py-breakpoint-create-fail.py: New testcase. --- gdb/python/py-breakpoint.c | 1 + .../gdb.python/py-breakpoint-create-fail.c | 28 +++++++++++ .../gdb.python/py-breakpoint-create-fail.exp | 58 ++++++++++++++++++++++ .../gdb.python/py-breakpoint-create-fail.py | 31 ++++++++++++ 4 files changed, 118 insertions(+) create mode 100644 gdb/testsuite/gdb.python/py-breakpoint-create-fail.c create mode 100644 gdb/testsuite/gdb.python/py-breakpoint-create-fail.exp create mode 100644 gdb/testsuite/gdb.python/py-breakpoint-create-fail.py diff --git a/gdb/python/py-breakpoint.c b/gdb/python/py-breakpoint.c index ed9cae6..5918bcc 100644 --- a/gdb/python/py-breakpoint.c +++ b/gdb/python/py-breakpoint.c @@ -705,6 +705,7 @@ bppy_init (PyObject *self, PyObject *args, PyObject *kwargs) } CATCH (except, RETURN_MASK_ALL) { + bppy_pending_object = NULL; PyErr_Format (except.reason == RETURN_QUIT ? PyExc_KeyboardInterrupt : PyExc_RuntimeError, "%s", except.message); diff --git a/gdb/testsuite/gdb.python/py-breakpoint-create-fail.c b/gdb/testsuite/gdb.python/py-breakpoint-create-fail.c new file mode 100644 index 0000000..c346bdd --- /dev/null +++ b/gdb/testsuite/gdb.python/py-breakpoint-create-fail.c @@ -0,0 +1,28 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2016 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see <http://www.gnu.org/licenses/>. */ + +int +foo (int a) +{ + return a * 2; +} + +int +main (void) +{ + return foo (2); +} diff --git a/gdb/testsuite/gdb.python/py-breakpoint-create-fail.exp b/gdb/testsuite/gdb.python/py-breakpoint-create-fail.exp new file mode 100644 index 0000000..68cdccd --- /dev/null +++ b/gdb/testsuite/gdb.python/py-breakpoint-create-fail.exp @@ -0,0 +1,58 @@ +# Copyright (C) 2016 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +# This file is part of the GDB testsuite. It tests proper handling for +# breakpoint creation failure. + +load_lib gdb-python.exp + +standard_testfile + +if { [prepare_for_testing ${testfile}.exp ${testfile} ${srcfile}] } { + return -1 +} + +# Skip all tests if Python scripting is not enabled. +if { [skip_python_tests] } { continue } + +clean_restart "${testfile}" +if ![runto_main] { + perror "could not run to main" + continue +} + +# The following will create a breakpoint Python wrapper whose construction will +# abort: the requested symbol is not defined. GDB should not keep a reference +# to the wrapper; however it used to... +gdb_test "source py-breakpoint2.py" + +# ... and when it did, as a result, the following breakpoint creation (not +# initiated by the Python API) would dereference the already-freed Python +# breakpoint wrapper, resulting in undefined behavior, sometimes observed as a +# gdb crash, and other times causing the next stop to invoke the Python wrapper +# "stop" method for the object that is not supposed to exist. +gdb_test "break foo" + +# ... eventually, triggering this breakpoint will invoke the Python wrapper +# "stop" method for an object that is not supposed to exist. +set test "continuing to foo" +gdb_test_multiple "continue" "$test" { + -re "MyBP\.stop was invoked\!.*$gdb_prompt $" { + fail "$test" + } + -re "Continuing.*Breakpoint 2, foo.*$gdb_prompt $" { + pass "$test" + } +} diff --git a/gdb/testsuite/gdb.python/py-breakpoint-create-fail.py b/gdb/testsuite/gdb.python/py-breakpoint-create-fail.py new file mode 100644 index 0000000..845eb0f --- /dev/null +++ b/gdb/testsuite/gdb.python/py-breakpoint-create-fail.py @@ -0,0 +1,31 @@ +# Copyright (C) 2016 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +import gdb + + +class MyBP(gdb.Breakpoint): + def stop(self): + print('MyBP.stop was invoked!') + # Don't make this breakpoint stop + return False + + +try: + bp = MyBP('does_not_exist', gdb.BP_WATCHPOINT) +except RuntimeError: + pass +else: + assert False -- 2.8.3 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Fix use of a dangling pointer for Python breakpoint objects 2016-06-27 9:11 ` Pierre-Marie de Rodat @ 2016-06-27 10:03 ` Pedro Alves 2016-06-27 10:13 ` Pierre-Marie de Rodat 0 siblings, 1 reply; 7+ messages in thread From: Pedro Alves @ 2016-06-27 10:03 UTC (permalink / raw) To: Pierre-Marie de Rodat, gdb-patches On 06/27/2016 10:11 AM, Pierre-Marie de Rodat wrote: > +gdb_test "source py-breakpoint2.py" This is still sourcing the old filename. > + > +# ... and when it did, as a result, the following breakpoint creation (not > +# initiated by the Python API) would dereference the already-freed Python > +# breakpoint wrapper, resulting in undefined behavior, sometimes observed as a > +# gdb crash, and other times causing the next stop to invoke the Python wrapper > +# "stop" method for the object that is not supposed to exist. > +gdb_test "break foo" > + > +# ... eventually, triggering this breakpoint will invoke the Python wrapper > +# "stop" method for an object that is not supposed to exist. Remove this sentence, it no longer makes sense to have it. > +set test "continuing to foo" > +gdb_test_multiple "continue" "$test" { > + -re "MyBP\.stop was invoked\!.*$gdb_prompt $" { > + fail "$test" > + } > + -re "Continuing.*Breakpoint 2, foo.*$gdb_prompt $" { > + pass "$test" > + } > +} OK with the above fixed. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Fix use of a dangling pointer for Python breakpoint objects 2016-06-27 10:03 ` Pedro Alves @ 2016-06-27 10:13 ` Pierre-Marie de Rodat 0 siblings, 0 replies; 7+ messages in thread From: Pierre-Marie de Rodat @ 2016-06-27 10:13 UTC (permalink / raw) To: Pedro Alves, gdb-patches On 06/27/2016 12:03 PM, Pedro Alves wrote: > On 06/27/2016 10:11 AM, Pierre-Marie de Rodat wrote: > >> +gdb_test "source py-breakpoint2.py" > > This is still sourcing the old filename. Blarf, sorry about this! I checked the testcase still fails as expected with an old GDB this time. >> +# ... eventually, triggering this breakpoint will invoke the Python wrapper >> +# "stop" method for an object that is not supposed to exist. > > Remove this sentence, it no longer makes sense to have it. Done. > OK with the above fixed. Thank you! This is pushed, now. -- Pierre-Marie de Rodat ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-06-27 10:13 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-06-21 10:40 [PATCH] Fix use of a dangling pointer for Python breakpoint objects Pierre-Marie de Rodat 2016-06-23 16:15 ` Pedro Alves 2016-06-24 9:21 ` Pierre-Marie de Rodat 2016-06-24 16:41 ` Pedro Alves 2016-06-27 9:11 ` Pierre-Marie de Rodat 2016-06-27 10:03 ` Pedro Alves 2016-06-27 10:13 ` Pierre-Marie de Rodat
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).