)]}'
{
  "commit": "e527ca9876e75b29d28a499e6dd70b3991a7d4e1",
  "tree": "2effbadd83489da6f876a7430a39cf0a97363aa7",
  "parents": [
    "8dd69d99fec222b14fba21bcae569b2210be7401"
  ],
  "author": {
    "name": "Kaylee Lubick",
    "email": "kjlubick@google.com",
    "time": "Wed Oct 08 15:04:26 2025 -0700"
  },
  "committer": {
    "name": "Dawn LUCI CQ",
    "email": "dawn-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Wed Oct 08 15:04:26 2025 -0700"
  },
  "message": "Avoid use-after-move in Blob.h\n\nI noticed some interesting crashes [1] when working on an unrelated\ntask. Gemini pointed out that it\u0027s probably not a good idea to hold onto\nvec\u0027s data pointer after we\u0027ve moved it. While much of the time the new\nvector might take over the underlying pointer, this won\u0027t work if the\nvector implementation uses Small Vector Optimization (SVO). In that case\nvec.data() would be pointing to the stack and then after the move (which\ncopies the stack data to the heap) the pointer is invalid.\n\nBy grabbing the data and size from the moved vector, we\u0027ll avoid the\ninvalid pointer.\n\n[1]\nhttps://logs.chromium.org/logs/skia/73de020340d43911/+/steps/dm/0/stdout\n\nChange-Id: I3548d2c414a43ad0388996466496e1644f3eef67\nReviewed-on: https://dawn-review.googlesource.com/c/dawn/+/265755\nReviewed-by: Kai Ninomiya \u003ckainino@chromium.org\u003e\nReviewed-by: Loko Kung \u003clokokung@google.com\u003e\nCommit-Queue: Kaylee Lubick \u003ckjlubick@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "9dc86d1d102c8a97228656f7a75b08d9305c240b",
      "old_mode": 33188,
      "old_path": "src/dawn/native/Blob.h",
      "new_id": "cddcb2661bdb65c644ee26bcd52febf65d5c3170",
      "new_mode": 33188,
      "new_path": "src/dawn/native/Blob.h"
    }
  ]
}
