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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Wed, 06 Mar 2013 19:07:42 +0100, Metzger, Markus T wrote:
> I'm not quite sure what the OS will do if tracing is requested twice for the same
> thread, i.e. repeated "record stop" followed by "record btrace" .  We may get
> an error or we may get a second buffer, thus leaking resources (i.e. the mmapped
> trace buffer).  We will need another target method to disable branch tracing
> that is called by the "record stop" command.

Yes, thanks for catching it, "record stop" needs to call real btrace_disable
before unpushing the target.


> In a gdbserver --multi session, I would expect that we're leaking the mmapped trace
> buffer also on re-run.

During re-run the first process gets killed first, so btrace_clear on the GDB
side is appropriate in such case.

On the gdbserver side there is linux_disable_btrace still called:
#0  linux_disable_btrace (tinfo=0x66fd40) at ../common/linux-btrace.c:509
#1  in remove_thread (thread=0x66f900) at inferiors.c:165
#2  in delete_lwp (lwp=0x66f7d0) at linux-low.c:334
#3  in delete_lwp_callback (entry=0x66f7d0, proc=0x66f660) at linux-low.c:1234
#4  in find_inferior (list=0x666540 <all_lwps>, func=0x425c61 <delete_lwp_callback>, arg=0x66f660) at inferiors.c:185
#5  in linux_mourn (process=0x66f660) at linux-low.c:1248
#6  in linux_kill (pid=28282) at linux-low.c:1058
#7  in kill_inferior (pid=28282) at target.c:190
#8  in handle_v_kill (own_buf=0x667370 "vKill;6e7a") at server.c:2273
#9  in handle_v_requests (own_buf=0x667370 "vKill;6e7a", packet_len=10, new_packet_len=0x7fffffffd7c8) at server.c:2345
#10 in process_serial_event () at server.c:3484

So I find that OK.


> I think this can be handled with an appropriate to_create_inferior method.

I do not see a reason for that hook - could you be more specific?


Thanks,
Jan