Hi Ulrich, Tom and community, Yes, it resolves the issue. Thank you so much for all the support and guidance Ulrich, Tom and community. Kindly let me know if any changes. If not kindly push these changes. Kindly see the outputs for both parent and child follow cases for the same code in the previous email pasted below. Kindly find attached the patch. {See: 0001-Fix-multi-thread-debug-bug-in-AIX.patch} Have a nice day ahead. Thanks and regards, Aditya. --------------------- Output with following child Reading symbols from /home/aditya/gdb_tests/ultimate-multi-thread-fork... (gdb) set detach-on-fork off (gdb) set follow-fork-mode child (gdb) r Starting program: /home/aditya/gdb_tests/ultimate-multi-thread-fork [New Thread 258] [New Thread 515] [Attaching after Thread 515 fork to child process 10748334] [New inferior 2 (process 10748334)] [Attaching after process 10748334 fork to child process 9568638] [New inferior 3 (process 9568638)] I am grandchild Reading symbols from /home/aditya/gdb_tests/ultimate-multi-thread-fork... Thread 3.1 received signal SIGINT, Interrupt. [Switching to process 9568638] thread_function (arg=0x0) at /home/aditya/gdb_tests/ultimate-multi-thread-fork.c:32 32 while (1); /* break here */ ------------------- Output with following parent 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 Thread 515] [New inferior 2 (process 9568642)] I am parent [New inferior 3 (process 15991254)] I am parent Thread 1.2 received signal SIGINT, Interrupt. [Switching to Thread 258] thread_function (arg=0x0) at /home/aditya/gdb_tests/ultimate-multi-thread-fork.c:32 32 while (1); /* break here */ (gdb) info sharedlibrary From To Syms Read Shared Object Library 0xd05bc124 0xd05bf194 Yes (*) /usr/lib/libpthreads.a(shr_comm.o) 0xd05bb240 0xd05bb9a1 Yes (*) /usr/lib/libcrypt.a(shr.o) 0xd0576180 0xd05ba731 Yes (*) /usr/lib/libpthread.a(shr_xpg5.o) 0xd0100e00 0xd0575123 Yes (*) /usr/lib/libc.a(shr.o) (*): Shared library is missing debugging information. (gdb) info inferiors Num Description Connection Executable * 1 process 18743566 1 (native) /home/aditya/gdb_tests/ultimate-multi-thread-fork 2 process 9568642 1 (native) /home/aditya/gdb_tests/ultimate-multi-thread-fork 3 process 15991254 1 (native) /home/aditya/gdb_tests/ultimate-multi-thread-fork (gdb) From: Ulrich Weigand Date: Friday, 17 February 2023 at 5:34 PM 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: >GDB has three things to do here. >** It will get a new object file notifier of the new process, >** new inferior is created so the new inferior notifier >** And follow_fork () event since GDB must decide it has to follow the child. >Note:- Our child process is > >This is the exact order in which the above 3 things will be executed from the >main GDB event loop. Hmm. I understood the order to be a bit different. I agree there will first be new objfile notifiers for the main executable and shared libraries. But then we should get to infrun.c:follow_fork, which calls infrun.c:follow_fork_inferior, which does in sequence: switch_to_thread (*child_inf->threads ().begin ()); post_create_inferior (0); So it should *first* do the switch_to_thread, and only *then* call post_create_inferior (which in turn triggers the new inferior notifier). As a result, I understand it should be fine to switch ptid_t in the new inferior notifier. But I agree that already switching it in the new objfile notifier is a problem. I see that linux-thread-db.c has special code for that: /* When attaching / handling fork child, don't try loading libthread_db until we know about all shared libraries. */ if (inf->in_initial_library_scan) return false; I believe you need to similarly skip calling pd_activate from pd_enable if that in_initial_library_scan flag is true for the current inferior. Can you try if this resolves the problem? Bye, Ulrich