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

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

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

>>Yes. So we have a little more to understand here. So once pd_enable () 
>>was called and then pd_activate () was called it looks like either 
>>the libraries were not fully loaded though the pthdb_session_pthreaded 
>>successful or the create thread event breakpoint was not successful.
>>So the code execution did not reach >>pd_activate (). Therefore our
>>child process was still ptid_t (pid, 0 ,0). When I used the pd_activate ()
>>inside the update_threadlist () it succeeded to initialise a session
>>later on when it was called and then we were able to set pd_active
>>and get to sync_threadlists ().
>
>I can confirm that this condition
>/* When attaching / handling fork child, don't try activating
>     thread debugging until we know about all shared libraries.  */
>  if (inf->in_initial_library_scan)
>    return;
>
>is what is the reason we fail to reach pd_activate ().. Sorry for not being clear in my previous email..

OK, so this raises two questions:

- I think we never should call pd_activate twice on a process
  where pd_active is already true.  This can now happen when
  you call pd_activate from update_thread_list.

- Do we even need the in_initial_library_scan check at all
  anymore? I seem to recall we added that as the
  sync_threadlists call could cause confusion during early
  startup.  But now that we don't call sync_threadlists
  from pd_activate any more, maybe we can simply remove that
  check completely?  And then, maybe we no longer need to
  call pd_active from update_thread_list.

Minor issues I noticed in the patch:

- Variable "data" in update_thread_list looks unused?
- Some whitespace issues - please watch the TAB settings,
  in the GDB sources a TAB should be 8 spaces.

Bye,
Ulrich