Re: [PATCH] Fix use of a dangling pointer for Python breakpoint objects

[Pedro Alves <palves@redhat.com>]

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