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

Jan Kratochvil
2013-03-07T09:06:48Z

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