)]}'
{
  "commit": "da474da158e09787f2a36f480bfa1b79160a0e91",
  "tree": "db1abf5369ec3f18e8ff2620858adf9dac9b1fda",
  "parents": [
    "8188f382a1ce6f8123d03e4a9cf14071f3085587"
  ],
  "author": {
    "name": "Simon Marchi",
    "email": "simon.marchi@efficios.com",
    "time": "Fri Sep 10 16:42:53 2021 -0400"
  },
  "committer": {
    "name": "Simon Marchi",
    "email": "simon.marchi@polymtl.ca",
    "time": "Mon Sep 27 16:55:46 2021 -0400"
  },
  "message": "gdb: don\u0027t share aspace/pspace on fork with \"detach-on-fork on\" and \"follow-fork-mode child\"\n\nWe found that when handling forks, two inferiors can unexpectedly share\ntheir program space and address space.  To reproduce:\n\n 1. Using a test program that forks...\n 2. \"set follow-fork-mode child\"\n 3. \"set detach-on-fork on\" (the default)\n 4. run to a breakpoint somewhere after the fork\n\nStep 4 should have created a new inferior:\n\n    (gdb) info inferiors\n      Num  Description       Connection           Executable\n      1    \u003cnull\u003e                                 /home/smarchi/build/wt/amd/gdb/fork\n    * 2    process 251425    1 (native)           /home/smarchi/build/wt/amd/gdb/fork\n\nBy inspecting the state of GDB, we can see that the two inferiors now\nshare one program space and one address space:\n\nInferior 1:\n\n    (top-gdb) p inferior_list.m_front.num\n    $2 \u003d 1\n    (top-gdb) p inferior_list.m_front.aspace\n    $3 \u003d (struct address_space *) 0x5595e2520400\n    (top-gdb) p inferior_list.m_front.pspace\n    $4 \u003d (struct program_space *) 0x5595e2520440\n\nInferior 2:\n\n    (top-gdb) p inferior_list.m_front.next.num\n    $5 \u003d 2\n    (top-gdb) p inferior_list.m_front.next.aspace\n    $6 \u003d (struct address_space *) 0x5595e2520400\n    (top-gdb) p inferior_list.m_front.next.pspace\n    $7 \u003d (struct program_space *) 0x5595e2520440\n\nYou can then run inferior 1 again and the two inferiors will still\nerroneously share their spaces, but already at this point this is wrong.\n\nThe cause of the bad {a,p}space sharing is in follow_fork_inferior.\nWhen following the child and detaching from the parent, we just re-use\nthe parent\u0027s spaces, rather than cloning them.  When we switch back to\ninferior 1 and run again, we find ourselves with two unrelated inferiors\nsharing spaces.\n\nFix that by creating new spaces for the parent after having moved them\nto the child.  My initial implementation created new spaces for the\nchild instead.  Doing this breaks doing \"next\" over fork().  When \"next\"\nstart, we record the symtab of the starting location.  When the program\nstops, we compare that symtab with the symtab the program has stopped\nat.  If the symtab or the line number has changed, we conclude the\n\"next\" is done.  If we create a new program space for the child and copy\nthe parent\u0027s program space to it with clone_program_space, it creates\nnew symtabs for the child as well.  When the child stop, but still on\nthe fork() line, GDB thinks the \"next\" is done because the symtab\npointers no longer match.  In reality they are two symtab instances that\nrepresent the same file.  But moving the spaces to the child and\ncreating new spaces for the parent, we avoid this problem.\n\nNote that the problem described above happens today with \"detach-on-fork\noff\" and \"follow-fork-mode child\", because we create new spaces for the\nchild.  This will have to be addressed later.\n\nTest-wise, improve gdb.base/foll-fork.exp to set a breakpoint that is\nexpected to have a location in each inferiors.  Without the fix, when\nthe two inferiors erroneously share a program space, GDB reports a\nsingle location.\n\nChange-Id: Ifea76e14f87b9f7321fc3a766217061190e71c6e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "0acb3f779b5abca3621a7e3082441d317ffe4e6c",
      "old_mode": 33188,
      "old_path": "gdb/infrun.c",
      "new_id": "5fd1ade7c6844a0379aa338748bc1607e9379d11",
      "new_mode": 33188,
      "new_path": "gdb/infrun.c"
    },
    {
      "type": "modify",
      "old_id": "3a0cc2fe45685680745819e4886761a2c9b162a9",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/gdb.base/foll-fork.exp",
      "new_id": "7f9e1cf87c6a657a8ccc5945cd414d5e216cc027",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.base/foll-fork.exp"
    }
  ]
}