)]}'
{
  "commit": "6d3717d4c412db52b33fa53f0ea9fc52f3d0aadc",
  "tree": "0a829ee65e92084a2bc34ac19246fd91bedb1d56",
  "parents": [
    "dcee6fb39812ace0df59b8d0dd43cd41d2f02e54"
  ],
  "author": {
    "name": "Simon Marchi",
    "email": "simon.marchi@efficios.com",
    "time": "Mon Jan 30 15:02:48 2023 -0500"
  },
  "committer": {
    "name": "Simon Marchi",
    "email": "simon.marchi@polymtl.ca",
    "time": "Wed Feb 08 16:31:30 2023 -0500"
  },
  "message": "gdb: call frame unwinders\u0027 dealloc_cache methods through destroying the frame cache\n\nCurrently, some frame resources are deallocated by iterating on the\nframe chain (starting from the sentinel), calling dealloc_cache.  The\nproblem is that user-created frames are not part of that chain, so we\nnever call dealloc_cache for them.\n\nI propose to make it so the dealloc_cache callbacks are called when the\nframes are removed from the frame_stash hash table, by registering a\ndeletion function to the hash table.  This happens when\nframe_stash_invalidate is called by reinit_frame_cache.  This way, all\nframes registered in the cache will get their unwinder\u0027s dealloc_cache\ncallbacks called.\n\nNote that at the moment, the sentinel frames are not registered in the\ncache, so we won\u0027t call dealloc_cache for them.  However, it\u0027s just a\ntheoritical problem, because the sentinel frame unwinder does not\nprovide this callback.  Also, a subsequent patch will change things so\nthat sentinel frames are registered to the cache.\n\nI moved the obstack_free / obstack_init pair below the\nframe_stash_invalidate call in reinit_frame_cache, because I assumed\nthat some dealloc_cache would need to access some data on that obstack,\nso it would be better to free it after clearing the hash table.\n\nChange-Id: If4f9b38266b458c4e2f7eb43e933090177c22190\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "a08a8f47ebc4142d016dde6acc206703f76da034",
      "old_mode": 33188,
      "old_path": "gdb/frame.c",
      "new_id": "fed961b2a8dfb46144c49450d1b1ac9bc5909961",
      "new_mode": 33188,
      "new_path": "gdb/frame.c"
    }
  ]
}
