Re: [PATCH] Fix AIX thread NULL assertion failure during fork

[Ulrich Weigand <Ulrich.Weigand@de.ibm.com>]

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>>So how is it possible that in between wait () setting the child_ptid and infrun.c
>>using it to switch to the child, the child is becoming multi-threaded?  Where is
>>the sync_threadlists () call that makes this happen?
>
>>I think we should understand better how this could have happened.
> 
>I’m sorry I missed an information to tell you. So the parent process is loaded it is
>multi-threaded, child is loaded and through wait we have informed that fork () event
>has happened and given the GDB core its required information.
> 
>This child now will have its object file which will be loaded soon. So new_objfile ()
>is called which will inturn call pd_enable () and this function will call pd_activate ()
>then pd_update (), then sync_threadlists ().

Ah, I see. new_objfile is called from clone_program_space, which is
called from within follow_fork_inferior.  If this changes the child's
main thread ptid under the covers, then any future use of child_ptid
in follow_fork_inferior / follow_fork will be incorrect.

Now, the question is whether new_objfile should actually do that.
I believe that in current GDB, the answer is actually no.  While
in the past, platform-specific thread targets were indeed supposed
to do that, it seems this has been changed a while ago.  Today,
none of the other thread targets do that, as far as I can see.

Instead, there is a new ::update_thread_list target hook that
common code calls at appropriate times (when it expects ptids
to change).  I think you need to look into removing the call to
sync_threadlists from new_objfile and instead implement the
update_thread_list hook and perform that call there.

I believe you still need to perform the pd_enable / pd_activate
tasks during new_objfile, but no longer automatically call
pd_update.  The latter should be moved to update_thread_list.


Bye,
Ulrich