)]}'
{
  "commit": "2b142a9f83f56fbbc1c9fe45f2ea19cd11db2795",
  "tree": "d2b613d3533cf80c11c73930690a5272bd7153ad",
  "parents": [
    "7a283d9cf5ccf26321f33812e79cf1515288ac94"
  ],
  "author": {
    "name": "Simon Marchi",
    "email": "simon.marchi@efficios.com",
    "time": "Fri Nov 04 10:07:09 2022 -0400"
  },
  "committer": {
    "name": "Simon Marchi",
    "email": "simon.marchi@efficios.com",
    "time": "Tue Nov 08 16:51:35 2022 -0500"
  },
  "message": "gdb/linux-nat: get core count using /sys/devices/system/cpu/possible\n\nI get this test failure on my CI;\n\n  FAIL: gdb.base/info-os.exp: get process list\n\nThe particularity of this setup is that builds are done in containers\nwho are allocated 4 CPUs on a machine that has 40.  The code in\nnat/linux-osdata.c fails to properly fetch the core number for each\ntask.\n\nlinux_xfer_osdata_processes uses `sysconf (_SC_NPROCESSORS_ONLN)`, which\nreturns 4, so it allocates an array of 4 integers.  However, the core\nnumbers read from /proc/pid/task/tid/stat, by function\nlinux_common_core_of_thread, returns a value anywhere between 0 and 39.\nThe core numbers above 3 are therefore ignored, many processes end up\nwith no core value, and the regexp in the test doesn\u0027t match (it\nrequires an integer as the core field).\n\nThe way this the CPUs are exposed to the container is that the container\nsees 40 CPUs \"present\" and \"possible\", but only 4 arbitrary CPUs\nactually online:\n\n    root@ci-node-jammy-amd64-04-08:~# cat /sys/devices/system/cpu/present\n    0-39\n    root@ci-node-jammy-amd64-04-08:~# cat /sys/devices/system/cpu/online\n    5,11,24,31\n    root@ci-node-jammy-amd64-04-08:~# cat /sys/devices/system/cpu/possible\n    0-39\n\nThe solution proposed in this patch is to find out the number of\npossible CPUs using /sys/devices/system/cpu/possible.  In practice, this\nwill probably always contain `0-N`, where N is the number of CPUs, minus\none.  But the documentation [1] doesn\u0027t such guarantee, so I\u0027ll assume\nthat it can contain a more complex range list such as `2,4-31,32-63`,\nlike the other files in that directory can have.  The solution is to\niterate over these numbers to find the highest possible CPU id, and\nuse that that value plus one as the size of the array to allocate.\n\n[1] https://www.kernel.org/doc/Documentation/admin-guide/cputopology.rst\n\nChange-Id: I7abce2e43b000c1327fa94cd7b99d46e49d7ccf3\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "f9c43f6691e9a1fa33764193009fdd4bb3c1ab84",
      "old_mode": 33188,
      "old_path": "gdb/nat/linux-osdata.c",
      "new_id": "8639f090910a95c3255698f027335317f33b9a4d",
      "new_mode": 33188,
      "new_path": "gdb/nat/linux-osdata.c"
    }
  ]
}