)]}'
{
  "commit": "e9fc42cf0567df6e309bfbdbaa9aed66d4ccd423",
  "tree": "cd6f4861568baa785223e7b091abf7b4dc1454e9",
  "parents": [
    "70e01ad62ec25e434ddbc7ba339a64e4b1b9c464"
  ],
  "author": {
    "name": "Pedro Alves",
    "email": "pedro@palves.net",
    "time": "Wed May 07 18:29:56 2025 +0100"
  },
  "committer": {
    "name": "Pedro Alves",
    "email": "pedro@palves.net",
    "time": "Thu Apr 30 18:37:32 2026 +0100"
  },
  "message": "Add gdb.threads/leader-exit-schedlock.exp\n\nThis adds a new test for letting the main thread exit the process with\nscheduler-locking on, while there are other threads live.\n\nOn Linux, when the main thread exits without causing a whole-process\nexit (e.g., via the main thread doing pthread_exit), the main thread\nbecomes zombie but does not report a thread exit event.  When\neventually all other threads of the process exit, the main thread is\nunblocked out of its zombie state and reports its exit which we\ninterpret as the whole-process exit.\n\nIf the main-thread-exit causes a whole-process exit (e.g., via the\nexit syscall), the process is the same, except that the exit syscall\nmakes the kernel force-close all threads immediately.\n\nImportantly, the main thread on Linux is always the last thread that\nreports the exit event.\n\nOn Windows, the main thread exiting is not special at all.  When the\nmain thread causes a process exit (e.g., for ExitProcess or by\nreturning from main), the debugger sees a normal thread exit event for\nthe main thread.  All other threads will follow up with a thread-exit\nevent too, except whichever thread happens to be the last one.  That\nlast one is the one that reports a whole-process-exit event instead of\nan exit-thread event.  So, since programs are typically multi-threaded\non Windows (because the OS/runtime spawns some threads), when the main\nthread just returns from main(), it is very typically _not_ the main\nthread that reports the whole-process exit.\n\nAs a result, stepping the main thread with schedlock on Windows\nresults in the main thread exiting and the continue aborting due to\nno-resumed-threads left instead of a whole-process exit as seen on\nLinux:\n\n(gdb) info threads\n  Id   Target Id                                    Frame\n* 1    Thread 11768.0x1bc \"leader-exit-schedlock\"   main () at .../gdb.threads/leader-exit-schedlock.c:55\n  2    Thread 11768.0x31e0 (in kernel)              0x00007ffbb23dfc77 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  3    Thread 11768.0x2dec \"sig\" (in kernel)        0x00007ffbb23dc087 in ntdll!ZwReadFile () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  4    Thread 11768.0x2530 (in kernel)              0x00007ffbb23dfc77 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  5    Thread 11768.0x3384 \"leader-exit-schedlock\"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  6    Thread 11768.0x3198 \"leader-exit-schedlock\"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  7    Thread 11768.0x1ab8 \"leader-exit-schedlock\"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  8    Thread 11768.0x3fe4 \"leader-exit-schedlock\"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  9    Thread 11768.0x3b5c \"leader-exit-schedlock\"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  10   Thread 11768.0x45c \"leader-exit-schedlock\"   0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  11   Thread 11768.0x3724 \"leader-exit-schedlock\"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  12   Thread 11768.0x1e44 \"leader-exit-schedlock\"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  13   Thread 11768.0x23f0 \"leader-exit-schedlock\"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  14   Thread 11768.0x3b80 \"leader-exit-schedlock\"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n(gdb) set scheduler-locking on\n(gdb) c\nContinuing.\n[Thread 11768.0x1bc exited]\nNo unwaited-for children left.\n(gdb) info threads\n  Id   Target Id                                                     Frame\n  2    Thread 11768.0x31e0 (exiting)                                 0x00007ffbb23dfc77 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  3    Thread 11768.0x2dec \"sig\" (exiting)                           0x00007ffbb23dc087 in ntdll!ZwReadFile () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  4    Thread 11768.0x2530 (exiting)                                 0x00007ffbb23dfc77 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  5    Thread 11768.0x3384 \"leader-exit-schedlock\" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  6    Thread 11768.0x3198 \"leader-exit-schedlock\" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  7    Thread 11768.0x1ab8 \"leader-exit-schedlock\" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  8    Thread 11768.0x3fe4 \"leader-exit-schedlock\" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  9    Thread 11768.0x3b5c \"leader-exit-schedlock\" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  10   Thread 11768.0x45c \"leader-exit-schedlock\" (exiting)          0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  11   Thread 11768.0x3724 \"leader-exit-schedlock\" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  12   Thread 11768.0x1e44 \"leader-exit-schedlock\" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  13   Thread 11768.0x23f0 \"leader-exit-schedlock\" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  14   Thread 11768.0x3b80 \"leader-exit-schedlock\" (exiting process) 0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n\nThe current thread \u003cThread ID 1\u003e has terminated.  See `help thread\u0027.\n(gdb)\n\nThe \"(exiting)\" and \"(exiting process)\" threads are threads for which\nthe kernel already reported their exit to GDB\u0027s Windows backend (via\nWaitForDebugEvent), but the Windows backend hasn\u0027t yet reported the\nevent to infrun.  The events are still pending in windows-nat.c.\n\nThe \"(exiting process)\" thread above (thread 14) is the one that won\nthe process-exit event lottery on the Windows kernel side (because it\nwas the last to exit).  Continuing the (exiting) threads with\nschedlock enabled should result in the Windows backend reporting that\nthread\u0027s pending exit to infrun.  While continuing thread 14 should\nresult in the inferior exiting.  Vis:\n\n (gdb) c\n Continuing.\n [Thread 11768.0x31e0 exited]\n No unwaited-for children left.\n (gdb) t 14\n [Switching to thread 14 (Thread 11768.0x3b80)]\n #0  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n (gdb) c\n Continuing.\n [Inferior 1 (process 11768) exited normally]\n\nThe testcase continues all the (exiting) threads, one by one, and then\nfinally continues the (exiting process) one, expecting an inferior\nexit.\n\nThe testcase also tries a similar scenario: instead immediately\ncontinue the (exiting process) thread without continuing the others.\nThat should result in the inferior exiting immediately.\n\nIt is actually not guaranteed that the Windows backend will consume\nall the thread and process exit events out of the kernel before the\nfirst thread exit event is processed by infrun.  So often we will see\nfor example, instead:\n\n(gdb) info threads\n  Id   Target Id                                                     Frame\n  2    Thread 11768.0x31e0 (exiting)                                 0x00007ffbb23dfc77 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  3    Thread 11768.0x2dec \"sig\" (exiting)                           0x00007ffbb23dc087 in ntdll!ZwReadFile () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  4    Thread 11768.0x2530 (exiting)                                 0x00007ffbb23dfc77 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  5    Thread 11768.0x3384 \"leader-exit-schedlock\" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  6    Thread 11768.0x3198 \"leader-exit-schedlock\" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  7    Thread 11768.0x1ab8 \"leader-exit-schedlock\" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  8    Thread 11768.0x3fe4 \"leader-exit-schedlock\" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  9    Thread 11768.0x3b5c \"leader-exit-schedlock\" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  10   Thread 11768.0x45c \"leader-exit-schedlock\"                    0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  11   Thread 11768.0x3724 \"leader-exit-schedlock\"                   0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  12   Thread 11768.0x1e44 \"leader-exit-schedlock\"                   0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  13   Thread 11768.0x23f0 \"leader-exit-schedlock\" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n  14   Thread 11768.0x3b80 \"leader-exit-schedlock\" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll\n\nAbove, we can\u0027t tell which thread will get the exit-process event,\nthere is no \"(exiting process)\" thread.  We do know it\u0027ll be one of\nthreads 10, 11, and 12, because those do not have \"(exiting)\".  The\nWindows kernel has already decided which one it is at this point, we\njust haven\u0027t seen the exit-process event yet.\n\nThis is actually what we _always_ see with \"maint set target-non-stop\noff\" too, because in all-stop, the Windows backend only processes one\nWindows debug event at a time.\n\nSo when the the test first continues all the (exiting) threads, one by\none, and then when there are no more \"(exiting)\" threads, if there is\nno \"(exiting process)\" thread, it tries to exit the remaining threads,\n(in the above case threads 10, 11 and 12), expecting that one of those\ncontinues may cause an inferior exit.\n\nOn systems other than Windows, the testcase expects that continuing\nthe main thread results in an inferior exit.  If we find out that\nisn\u0027t correct for some system, we can adjust the testcase then.\n\nApproved-By: Tom Tromey \u003ctom@tromey.com\u003e\nChange-Id: I52fb8de5e72bc12195ffb8bedd1d8070464332d3\ncommit-id:5f751d8e\n",
  "tree_diff": [
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "cdd8780878fe0165532992a6d1111e4f29ddb95e",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.threads/leader-exit-schedlock.c"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "56e1634c42f039e7d7fe6b24a124699690365fff",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.threads/leader-exit-schedlock.exp"
    }
  ]
}