Re: [rfa/gdbserver] Fix crash in thread_db_get_tls_address

[Doug Evans <dje@google.com>]

On Wed, Jan 21, 2009 at 2:57 PM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> Hello,
>
> when debugging remotely using a GDB with private modifcations, I'm running
> into a crash in gdbserver, which I believe to be a real bug (even if latent
> with mainline GDB).
>
> The problem occurs when the thread_db_get_tls_address routine is invoked
> (as a result of processing a qGetTLSAddr: query) on an inferior that
> actually has no threads (or where the thread layer is not initialized yet).
>
> This is caused by thread_db_get_tls_address calling find_one_thread,
> which in the end calls down into the libthread_db td_ta_map_lwp2thr
> routine -- at a time libthread_db is not yet initialized, and in fact
> the "thread_agent" handle passed to td_ta_map_lwp2thr was not yet
> set up.  This results in a segfault within libthread_db.
>
> Now I guess it is debatable whether or not sending a qGetTLSAddr:
> query in this situation is a useful thing, but it seems to me that
> gdbserver shouldn't just *crash* ...
>
> The following patch fixes this by returning failure from
> thread_db_get_tls_address if called before the thread layer
> is properly initialized.
>
>
> Tested on powerpc64-linux (64-bit / 32-bit) using local gdbserver.
>
> OK for mainline?
>
> Bye,
> Ulrich
>
>
> ChangeLog:
>
>        * thread-db.c (thread_db_get_tls_address): Do not crash if
>        called when thread layer is not yet initialized.
>
>
> Index: src/gdb/gdbserver/thread-db.c
> ===================================================================
> --- src.orig/gdb/gdbserver/thread-db.c
> +++ src/gdb/gdbserver/thread-db.c
> @@ -388,6 +388,10 @@ thread_db_get_tls_address (struct thread
>   td_err_e err;
>   struct process_info *process;
>
> +  /* If the thread layer is not (yet) initialized, fail.  */
> +  if (!all_symbols_looked_up)
> +    return -1;
> +
>   process = get_thread_process (thread);
>   if (!process->thread_known)
>     find_one_thread (process->lwpid);
> --
>  Dr. Ulrich Weigand
>  GNU Toolchain for Linux on System z and Cell BE
>  Ulrich.Weigand@de.ibm.com
>

Hi.  I've run into similar situations with the thread layer not yet
initialized.  One aspect of this patch is a bit confusing.  Maybe a
comment is warranted.

Returning -1 will cause server.c:handle_query to mark the packet as
unknown which will in turn cause remote.c:packet_ok to mark the packet
as disabled (on the gdb side).  How does the packet get re-enabled if
the thread layer is later initialized?