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

Jan Kratochvil
2013-03-07T10:14:03Z

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