Crash of GDB with gdbserver btrace enabled [Re: [patch v9 00/23] branch tracing support for Atom]

Jan Kratochvil jan.kratochvil@redhat.com
Thu Mar 7 10:14:00 GMT 2013


On Thu, 07 Mar 2013 10:59:23 +0100, Metzger, Markus T wrote:
> > -----Original Message-----
> > From: Metzger, Markus T
> > Sent: Thursday, March 07, 2013 10:41 AM
> 
> 
> > Another approach would be to change pop_target to unpush the top target
> > instead of just closing it.  This would prevent btrace from finding a target to
> > disable tracing and all I would need to do is remove the tcomplain call in
> > target_disable_btrace.
> > 
> > This would be quite elegant but I have no clue about the side effects this
> > might have.
> 
> void
> pop_target (void)
> {
>   target_close (target_stack, 0);	/* Let it clean up.  */
>   if (unpush_target (target_stack) == 1)
>     return;
> 
>   fprintf_unfiltered (gdb_stderr,
> 		      "pop_target couldn't find target %s\n",
> 		      current_target.to_shortname);
>   internal_error (__FILE__, __LINE__,
> 		  _("failed internal consistency check"));
> }
> 
> Isn't pop_target closing the topmost target twice?
> 
> When I remove the first call to target_close and do not turn errors into
> warnings in record_btrace_close, the crash is gone.  I have no clue about
> the side effects of this, though.


OK, I agree target_close seems excessive here, it also does not correspond to
the current description of target_close:
	This routine is automatically always called after popping the target
	off the target stack

While it is nice cleanup I find it a separate patch, not required for btrace.


Thanks,
Jan



More information about the Gdb-patches mailing list