Hi Ulrich and community, Please find attached the patch {See: 0001-Fix-multi-thread-debug-bug-in-AIX.patch} So, I took into account the information you gave me the last time. Having said that, it turned out to be a different issue that is causing such a swap of threads as shown in the outputs of the previous email {pasted again below this email}. Our top target is getting set correctly and symbols are being read in the right way on any new-born inferior. I am thankful to you all for pointing that shared Library issue to me. While setting the top target for a new inferior we go to sync_threadlist () from the pd_enable () -> pthdb_session_pthreaded () -> push the top target -> pd_activate () -> pthdb_session_init ()-> pd_update () -> sync_threadlists (), our sync_threadlists uses a variable called gcount which represents the number of threads in the GDB. pcount is the number of pthreads. gcount is got from iterate_over_threads (). Honestly from my understanding we do not take into account the process ID while we iterate over threads. So, this will work in a single inferior case whereas in multi-inferior one with multi thread things mess up. Here is how: So, if we have two threads in our first inferior {main thread and a task thread say}, and one main thread in the second inferior and we are syncing our second inferior, though our pcount will correctly be one but our gcount will 3. Which means by our current logic we will end up deleting two threads {first two of the first inferior}. This is exactly what happened in my precious mail output if you check and post this, we will swap the threads as this is how the code flow. This is now one of the causes of the bug. Inorder to resolve the same I request for one information. How can we iterate_over_threads of a particular process. What is that function. Is there any built-in available?? Kindly let me know and that should solve this issue. Also kindly give me feedback on this patch if I need to change anything. I thank you for the guidance so far. Hoping for a reply soon. Have a nice day ahead. Thanks and regards, Aditya. -------------------------------------------- Output 2:- Reading symbols from /home/aditya/gdb_tests/ultimate-multi-thread-fork... (gdb) set detach-on-fork off (gdb) r Starting program: /home/aditya/gdb_tests/ultimate-multi-thread-fork [New Thread 258] [New inferior 2 (process 16122342)] I am parent ^C[New process 11665700] Thread 1.3 received signal SIGINT, Interrupt. 0xd0595fb0 in _p_nsleep () from /usr/lib/libpthread.a(shr_xpg5.o) (gdb) info threads Id Target Id Frame * 1.3 process 11665700 0xd0595fb0 in _p_nsleep () from /usr/lib/libpthread.a(shr_xpg5.o) 2.1 Thread 258 (tid 28115287, running) 0xd0594fc8 in _sigsetmask () from /usr/lib/libpthread.a(shr_xpg5.o) (gdb) ________________________________ From: Ulrich Weigand Sent: 11 January 2023 19:01 To: simark@simark.ca ; Aditya Kamath1 ; gdb-patches@sourceware.org Cc: Sangamesh Mallayya Subject: Re: [PATCH] 0001-Fix-multi-thread-debug-bug-in-AIX.patch Aditya Kamath1 wrote: >So, looking at this, I have missed out something may be minor or >major causing the bug which I am unaware of in the code base. The one problem I see is that there are still global variables that seem to get clobbered if there are multiple inferiors, in particular pd_session and pd_brk_addr. Those will get overwritten by each pd_activate call for each inferior. Note that pthdb_session_init registers the pid, so the resulting pd_session should be different for each inferior. If you just overwrite it, then the pid values passed to all callbacks will always reflect only the latest inferior. Similarly, pd_brk_addr is potentially different in each inferior, if libpthread is loaded at different addresses. You should create a struct containing all per-inferior thread- related data members, and then allocate one such struct per inferior. Bye, Ulrich