)]}'
{
  "commit": "f74a5e6f2ed5180ce28d6478a6d7a7a1982c5d43",
  "tree": "f6604c034273bc6a6222c7730dd3ae6361f0eef1",
  "parents": [
    "ecfc6ddb8074aff8882155b5900958725094f508"
  ],
  "author": {
    "name": "Lancelot SIX",
    "email": "lancelot.six@amd.com",
    "time": "Tue Aug 02 13:14:20 2022 +0100"
  },
  "committer": {
    "name": "Lancelot SIX",
    "email": "lancelot.six@amd.com",
    "time": "Wed Aug 03 09:57:40 2022 +0100"
  },
  "message": "gdb: Fix regression in varobj recreation\n\nCommit bc20e562ec0 \"Fix use after free in varobj\" introduced a\nregression.  This commit makes sure that the varobj object does not\nkeeps stale references to object being freed when we unload an objfile.\nThis includes the \"valid_block\" field which is reset to nullptr if the\npointed to block is tied to an objfile being freed.\n\nHowever, at some point varobj_invalidate_iter might try to recreate\nvarobjs tracking either floating or globals.  Varobj tracking globals\nare identified as having the \"valid_block\" field set nullptr, but as\nbc20e562ec0 might clear this field, we have lost the ability to\ndistinguish between varobj referring to globals and non globals.\n\nFix this by introducing a \"global\" flag which tracks if a given varobj\nwas initially created as tracking a global.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d29426\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "e558794617a27b2f655102f7278cf8b0bcb5cee2",
      "old_mode": 33188,
      "old_path": "gdb/varobj.c",
      "new_id": "0683af1991eeb23b669629e07307c2ed62fe6f89",
      "new_mode": 33188,
      "new_path": "gdb/varobj.c"
    }
  ]
}