[prev in list] [next in list] [prev in thread] [next in thread]
List: gdb-patches
Subject: [RFC] Fix for gdb crash in "info thread" after exec().
From: ppluzhnikov () google ! com (Paul Pluzhnikov)
Date: 2008-05-28 17:49:00
Message-ID: 8ac60eac0805271625j5a864522x6afb85f234e7c2c8 () mail ! gmail ! com
[Download RAW message or body]
On Tue, May 27, 2008 at 1:06 PM, Pedro Alves <pedro@codesourcery.com> wrote:
> Could you confirm that this hunk of my patch,
>
> Index: src/gdb/linux-thread-db.c
> ===================================================================
> --- src.orig/gdb/linux-thread-db.c 2008-05-06 12:22:31.000000000 +0100
> +++ src/gdb/linux-thread-db.c 2008-05-06 12:53:18.000000000 +0100
> @@ -840,7 +840,7 @@ thread_db_wait (ptid_t ptid, struct targ
> unpush_target (&thread_db_ops);
> using_thread_db = 0;
>
> - return pid_to_ptid (GET_PID (ptid));
> + return ptid;
> }
>
> /* If we do not know about the main thread yet, this would be a good time
> to
>
> ... fixes the issue,
Confirmed.
> and that you were hitting that new_thread_event piece
> in infrun.c:handle_inferior_event while handling a TARGET_WAITKIND_EXECD ?
I am not sure I understand that second question correctly.
The 'ecs->new_thread_event' is set to 0 while handling
TARGET_WAITKIND_EXECD, and add_thread() is not called for it.
> We may need some more interface cleanup to clear the current thread
> list across an exec, if the original process had threads, but I don't
> think your call is in the right place.
Yes, it did feel out of place to me as well.
Thanks,
--
Paul Pluzhnikov
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic