* [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).