From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30996 invoked by alias); 3 Mar 2015 10:49:17 -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 30983 invoked by uid 89); 3 Mar 2015 10:49:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mga11.intel.com Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Mar 2015 10:49:15 +0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 03 Mar 2015 02:49:14 -0800 X-ExtLoop1: 1 Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga001.fm.intel.com with ESMTP; 03 Mar 2015 02:49:12 -0800 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.145]) by IRSMSX101.ger.corp.intel.com ([163.33.3.153]) with mapi id 14.03.0195.001; Tue, 3 Mar 2015 10:49:11 +0000 From: "Metzger, Markus T" To: Pedro Alves CC: "gdb-patches@sourceware.org" Subject: RE: [PATCH] btrace: avoid tp != NULL assertion Date: Tue, 03 Mar 2015 10:49:00 -0000 Message-ID: References: <1423473902-2286-1-git-send-email-markus.t.metzger@intel.com> <54F4DF9D.3060400@redhat.com> In-Reply-To: <54F4DF9D.3060400@redhat.com> Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00060.txt.bz2 > -----Original Message----- > From: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] On Behalf Of Pedro Alves > Sent: Monday, March 2, 2015 11:10 PM > To: Metzger, Markus T > Cc: gdb-patches@sourceware.org > Subject: Re: [PATCH] btrace: avoid tp !=3D NULL assertion >=20 > On 02/09/2015 09:25 AM, Markus Metzger wrote: > > On some targets, I see the LWP field patched out of INFERIOR_PTID before > > calling record_btrace_fetch_registers. Looking to the respective linux= -nat > > versions, they use the PID field if the LWP field is zero. >=20 > Sorry, I'm not sold on this one. Please give more detail. >=20 > Which targets? What's the backtrace like? I saw this on a 32-bit Fedora 20 running on i5-4250U. When I debug it using a conditional breakpoint on the assert, I get: (gdb) rec b (gdb) n Breakpoint 1, record_btrace_fetch_registers (ops=3D0x974bfc0 ,=20 regcache=3D0x9a0a798, regno=3D8) at gdb/record-btrace.c:1202 1202 gdb_assert (tp !=3D NULL); (gdb) bt #0 record_btrace_fetch_registers (ops=3D0x974bfc0 , reg= cache=3D0x9a0a798, regno=3D8) at gdb/record-btrace.c:1202 #1 0x083f4ee2 in delegate_fetch_registers (self=3D0x974bfc0 , arg1=3D0x9a0a798,=20 arg2=3D8) at gdb/target-delegates.c:149 #2 0x08406562 in target_fetch_registers (regcache=3D0x9a0a798, regno=3D8) at gdb/target.c:3279 #3 0x08355255 in regcache_raw_read (regcache=3D0x9a0a798, regnum=3D8,=20 buf=3D0xbfffe6c0 "=A8\003\222\t=C08kI=F8=E6=FF=BFHO5\b\035]") at gdb/regcache.c:643 .... (gdb) up 3 #3 0x08355255 in regcache_raw_read (regcache=3D0x9a0a798, regnum=3D8,=20 buf=3D0xbfffe6c0 "=A8\003\222\t=C08kI=F8=E6=FF=BFHO5\b\035]") at gdb/re= gcache.c:643 643 target_fetch_registers (regcache, regnum); (gdb) l 638 && regcache_register_status (regcache, regnum) =3D=3D REG_UNKNOWN) 639 { 640 struct cleanup *old_chain =3D save_inferior_ptid (); 641=09 642 inferior_ptid =3D regcache->ptid; 643 target_fetch_registers (regcache, regnum); 644 do_cleanups (old_chain); 645=09 646 /* A number of targets can't access the whole set of raw 647 registers (because the debug API provides no means to get at (gdb) p regcache->ptid $3 =3D {pid =3D 23856, lwp =3D 0, tid =3D 0} (gdb) p *cleanup_chain $12 =3D {next =3D 0x9a25820, function =3D 0x83b9ebd = , free_arg =3D 0x0,=20 arg =3D 0x9a76088} (gdb) p *(ptid_t *)cleanup_chain->arg $13 =3D {pid =3D 23856, lwp =3D 23856, tid =3D 0} (gdb) I have no idea how regcache->ptid ended up with lwp=3D0. Here's the full backtrace in case it helps. (gdb) bt #0 record_btrace_fetch_registers (ops=3D0x974bfc0 , reg= cache=3D0x9a0a798, regno=3D8) at gdb/record-btrace.c:1202 #1 0x083f4ee2 in delegate_fetch_registers (self=3D0x974bfc0 , arg1=3D0x9a0a798,=20 arg2=3D8) at gdb/target-delegates.c:149 #2 0x08406562 in target_fetch_registers (regcache=3D0x9a0a798, regno=3D8) at gdb/target.c:3279 #3 0x08355255 in regcache_raw_read (regcache=3D0x9a0a798, regnum=3D8,=20 buf=3D0xbfffe6c0 "=A8\003\222\t=C08kI=F8=E6=FF=BFHO5\b\035]") at gdb/regcache.c:643 #4 0x083558a7 in regcache_cooked_read (regcache=3D0x9a0a798, regnum=3D8,=20 buf=3D0xbfffe6c0 "=A8\003\222\t=C08kI=F8=E6=FF=BFHO5\b\035]") at gdb/regcache.c:734 #5 0x08355de3 in regcache_cooked_read_unsigned (regcache=3D0x9a0a798, regn= um=3D8, val=3D0xbfffe738) at gdb/regcache.c:838 #6 0x0827a106 in i386_linux_resume (ops=3D0x9737ca0 , pti= d=3D..., step=3D1,=20 signal=3DGDB_SIGNAL_0) at gdb/i386-linux-nat.c:670 #7 0x08280c12 in linux_resume_one_lwp (lp=3D0x9a0a5b8, step=3D1, signo=3DG= DB_SIGNAL_0) at gdb/linux-nat.c:1529 #8 0x08281281 in linux_nat_resume (ops=3D0x98da608, ptid=3D..., step=3D1, = signo=3DGDB_SIGNAL_0) at gdb/linux-nat.c:1708 #9 0x0850738e in record_btrace_resume (ops=3D0x98da608, ptid=3D..., step= =3D1, signal=3DGDB_SIGNAL_0) at gdb/record-btrace.c:1760 #10 0x083f4b3d in delegate_resume (self=3D0x974bfc0 , ar= g1=3D..., arg2=3D1,=20 arg3=3DGDB_SIGNAL_0) at gdb/target-delegates.c:87 #11 0x08404b79 in target_resume (ptid=3D..., step=3D1, signal=3DGDB_SIGNAL_= 0) at gdb/target.c:2231 #12 0x083b0ecd in resume (step=3D1, sig=3DGDB_SIGNAL_0) at gdb/infrun.c:2387 #13 0x083b16fe in proceed (addr=3D18446744073709551615, siggnal=3DGDB_SIGNA= L_DEFAULT, step=3D1) at gdb/infrun.c:2731 #14 0x083a9d84 in step_once (skip_subroutines=3D1, single_inst=3D0, count= =3D1, thread=3D1) at gdb/infcmd.c:1121 #15 0x083a9a2f in step_1 (skip_subroutines=3D1, single_inst=3D0, count_stri= ng=3D0x0) at gdb/infcmd.c:977 #16 0x083a97a0 in next_command (count_string=3D0x0, from_tty=3D1) at gdb/infcmd.c:885 #17 0x082bda38 in do_cfunc (c=3D0x990a3e8, args=3D0x0, from_tty=3D1) at gdb/cli/cli-decode.c:105 #18 0x082c03a1 in cmd_func (cmd=3D0x990a3e8, args=3D0x0, from_tty=3D1) at gdb/cli/cli-decode.c:1893 #19 0x084c8768 in execute_command (p=3D0x9772ce1 "", from_tty=3D1) at gdb/top.c:476 #20 0x083d1f80 in command_handler (command=3D0x9772ce0 "n") at gdb/event-top.c:494 #21 0x083d249b in command_line_handler (rl=3D0x9a25ab8 "n") at gdb/event-top.c:692 #22 0x08528ae7 in rl_callback_read_char () at readline/callback.c:220 #23 0x083d1aa7 in rl_callback_read_char_wrapper (client_data=3D0x0) at gdb/event-top.c:171 #24 0x083d1ea3 in stdin_event_handler (error=3D0, client_data=3D0x0) at gdb/event-top.c:432 #25 0x083d0ff8 in handle_file_event (file_ptr=3D0x9a25638, ready_mask=3D1) at gdb/event-loop.c:657 #26 0x083d127b in gdb_wait_for_event (block=3D1) at gdb/event-loop.c:772 #27 0x083d0726 in gdb_do_one_event () at gdb/event-loop.c:309 #28 0x083d0777 in start_event_loop () at gdb/event-loop.c:334 #29 0x083d1ad0 in cli_command_loop (data=3D0x0) at gdb/event-top.c:186 #30 0x083c95a3 in current_interp_command_loop () at gdb/interps.c:317 #31 0x083ca72b in captured_command_loop (data=3D0x0) at gdb/main.c:321 #32 0x083c698f in catch_errors (func=3D0x83ca716 , f= unc_args=3D0x0,=20 errstring=3D0x8c65769 "", mask=3DRETURN_MASK_ALL) at gdb/exceptions.c:235 #33 0x083cba17 in captured_main (data=3D0xbfffef54) at gdb/main.c:1148 #34 0x083c698f in catch_errors (func=3D0x83caac1 , func_args= =3D0xbfffef54,=20 errstring=3D0x8c65769 "", mask=3DRETURN_MASK_ALL) at gdb/exceptions.c:235 #35 0x083cba42 in gdb_main (args=3D0xbfffef54) at gdb/main.c:1156 #36 0x080c7097 in main (argc=3D2, argv=3D0xbffff004) at gdb/gdb.c:32 (gdb) Regards, Markus. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052