)]}'
{
  "commit": "fa20c3de21cd86a90dfe94328626ce6730df3a63",
  "tree": "197632c923ece6fc3082ce5f31ed2fb0aac12d99",
  "parents": [
    "5d795c1f964a8223f4a2e3ce3636478fd90d1ef0"
  ],
  "author": {
    "name": "Tom de Vries",
    "email": "tdevries@suse.de",
    "time": "Sat Jan 10 07:36:39 2026 +0100"
  },
  "committer": {
    "name": "Tom de Vries",
    "email": "tdevries@suse.de",
    "time": "Sat Jan 10 07:36:39 2026 +0100"
  },
  "message": "[gdb/testsuite] Add missing wait in gdb.multi/sched-multi-add-inferior.exp\n\nWith a gdb build with -O0 and Address Sanitizer and test-case\ngdb.multi/sched-multi-add-inferior.exp, I get:\n...\nFAIL: $exp: target_type_1\u003dextended-remote: target_type_2\u003dextended-remote: \\\n  continue to function1\nFAIL: $exp: target_type_1\u003dextended-remote: target_type_2\u003dextended-remote: \\\n  continue to function2\nFAIL: $exp: target_type_1\u003dnative: target_type_2\u003dextended-remote: \\\n  continue to function1\nFAIL: $exp: target_type_1\u003dnative: target_type_2\u003dextended-remote: \\\n  continue to function2\nFAIL: $exp: target_type_1\u003dnative: target_type_2\u003dnative: continue to function1\nFAIL: $exp: target_type_1\u003dnative: target_type_2\u003dnative: continue to function2\n...\n\nIn more detail, for the target_type_1 \u003d\u003d target_type_2 \u003d\u003d native configuration,\nwe have:\n...\n(gdb) continue^M\nContinuing.^M\n[Switching to Thread 0x7ffff7cc02c0 (LWP 2514714)]^M\n^M\nThread 2.1 \"sched-multi-add\" hit Breakpoint 4, main (...) at multi-target.c:94^M\n94            function2 (); /* set break 2 here */^M\n(gdb) FAIL: $exp: target_type_1\u003dnative: target_type_2\u003dnative: \\\n  continue to function1\nthread apply 2.1 set wait_for_gdb \u003d 0^M\n^M\nThread 2.1 (Thread 0x7ffff7cc02c0 (LWP 2514714) \"sched-multi-add\"):^M\n(gdb) PASS: $exp: target_type_1\u003dnative: target_type_2\u003dnative: \\\n  thread apply 2.1 set wait_for_gdb \u003d 0\ncontinue^M\nContinuing.^M\n[Switching to Thread 0x7ffff7cc02c0 (LWP 2514718)]^M\n^M\nThread 3.1 \"sched-multi-add\" hit Breakpoint 3, main (...) at multi-target.c:93^M\n93            function1 (); /* set break 1 here */^M\n(gdb) FAIL: $exp: target_type_1\u003dnative: target_type_2\u003dnative: \\\n  continue to function2\n...\n\nThe situation is as follows:\n- there are two inferiors\n- due to \"set schedule-multiple on\", continue continues both inferiors\n- after the first continue, the test-case expects the breakpoint on thread 3.1\n  to trigger\n- instead, the breakpoint in thread 2.1 triggers\n\nThe mechanism by which this order is supposed to be guaranteed, is that thread\n2.1 is blocked, and only unblocked after thread 3.1 hits its breakpoint:\n...\n    # Unblock thread 2.1 and continue again.  This time, thread 2.1\n    # will hit a breakpoint.\n    gdb_test \"thread apply 2.1 set wait_for_gdb \u003d 0\" \".*\"\n...\n\nHowever, thread 2.1 is never blocked.\n\nFix this by adding the missing:\n...\n    gdb_test \"thread apply 2.1 set wait_for_gdb \u003d 1\" \".*\"\n...\n\nTested on x86_64-linux.\n\nApproved-by: Kevin Buettner \u003ckevinb@redhat.com\u003e\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d33540\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "03d502a3cf3b639c2d4644480c066c7ed4c0cffc",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/gdb.multi/sched-multi-add-inferior.exp",
      "new_id": "8be73ba44fa5a7c1ae5062a81742ba9dc79f75be",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.multi/sched-multi-add-inferior.exp"
    }
  ]
}