)]}'
{
  "commit": "453fb03fae2cddf2a8a275056f12c8290341734c",
  "tree": "eaaf58e2411570dac5f6b8b063fe4392b9349bbc",
  "parents": [
    "71db9462eb994327a79928fbbaee3f3675458df1"
  ],
  "author": {
    "name": "Nicolas Hillegeer",
    "email": "aktau@google.com",
    "time": "Wed Dec 18 06:08:59 2024 -0800"
  },
  "committer": {
    "name": "Gopher Robot",
    "email": "gobot@golang.org",
    "time": "Thu Dec 19 12:26:58 2024 -0800"
  },
  "message": "gocore: explicitly load symbols from executable ELF file\n\nThis fixes partial typing fails when the core in question is complete\n(meaning: no section has Filesz !\u003d Memsz). Such cores can be triggered\non Linux by writing (see core(5)):\n\n  echo 0x3f \u003e /proc/self/coredump_filter\n\nIn this case, none of the mem mappings are backed by the executable file\non disk. This meant that the previous readSymbols implementation only\nreads the core file (which it ignored anyway).\n\nInstead of looping over the mappings, read the symbols explicitly from\nthe executable.\n\nI added a test which fails before my change. I had to refactor the\ntesting code a little bit to make it easier to pass an environment\nvariable. Unfortunately, changing /proc/self/coredump_filter means\nwriting to a file. Pulling in a dependency on package os makes the\ndominator tests panic. For now I\u0027ve disabled these tests: we\u0027re not sure\nit worked well anyway (it must have crashed for non-trivial programs).\nThere may need to be more improvements in general typing/walking before\nre-enabling it. In principle, the dominator failure could be partially\navoided by using build tags and not running the dominator test when\ncoredump_filter doesn\u0027t need to be manipulated. But given what I wrote\nbefore, I don\u0027t see why we should bother.\n\nThe history of this is interesting:\n\n - https://go.dev/cl/137375 is the last good change to this part of the\n   code. It reads symbols from all loaded executables. Its CL\n   description mentions that this is required for PIE and mixed (e.g.:\n   Go/C++ binaries). Yet the PIE and (internal) mixed binary tests\n   continue to pass with this change:\n\n   - I found that PIE support didn\u0027t work and added it in\n     https://go.dev/cl/618977 (with tests). Perhaps this is a reference\n     to PIE support that was somehow removed in-between.\n   - viewcore does not explicitly support mixed binaries, in the sense\n     that it does not (attempt) to understand C objects. The PIE tests\n\n - https://go.dev/cl/506558 introduced the full core bug by replacing\n   the read from all executable files with an iteration of the mappings.\n\nChange-Id: I2538cd863da72a9ebfc9415b32a97bf962479b61\nReviewed-on: https://go-review.googlesource.com/c/debug/+/637415\nLUCI-TryBot-Result: Go LUCI \u003cgolang-scoped@luci-project-accounts.iam.gserviceaccount.com\u003e\nAuto-Submit: Michael Knyszek \u003cmknyszek@google.com\u003e\nReviewed-by: Michael Knyszek \u003cmknyszek@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "92bf9b3916b791c9ef19ed6d5b024fa627c9e040",
      "old_mode": 33188,
      "old_path": "internal/core/process.go",
      "new_id": "d7c000c1f3cee850ade6f80ecf69fcfe4d9962f9",
      "new_mode": 33188,
      "new_path": "internal/core/process.go"
    },
    {
      "type": "modify",
      "old_id": "02fdece0f23b1acb068c790a2d5cd4b0d8ece73b",
      "old_mode": 33188,
      "old_path": "internal/gocore/gocore_test.go",
      "new_id": "ac0ace50660a97930a8cf588b09e7b916fae895d",
      "new_mode": 33188,
      "new_path": "internal/gocore/gocore_test.go"
    },
    {
      "type": "modify",
      "old_id": "bd35566dfc00debf72ee87c40d090419ec328a77",
      "old_mode": 33188,
      "old_path": "internal/gocore/testdata/coretest/test.go",
      "new_id": "d0e8443e60a910d11d7ade8d823a448d6fe5be59",
      "new_mode": 33188,
      "new_path": "internal/gocore/testdata/coretest/test.go"
    }
  ]
}