From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88996 invoked by alias); 24 Jun 2016 16:41:48 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 88974 invoked by uid 89); 24 Jun 2016 16:41:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=13286, moon, 901, * X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 24 Jun 2016 16:41:36 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4284A80096; Fri, 24 Jun 2016 16:41:35 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5OGfXUP013440; Fri, 24 Jun 2016 12:41:34 -0400 Subject: Re: [PATCH] Fix use of a dangling pointer for Python breakpoint objects To: Pierre-Marie de Rodat , gdb-patches@sourceware.org References: <20160621104021.15093-1-derodat@adacore.com> <02138a22-5087-44ad-6023-7c87251f3d19@redhat.com> From: Pedro Alves Message-ID: Date: Fri, 24 Jun 2016 16:41:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2016-06/txt/msg00401.txt.bz2 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