{
 "tokens": {
  "input": 27921,
  "cache_read": 116752,
  "cache_write": 14594,
  "output": 3583
 },
 "reviews": [
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz",
    "main criu-4.3/criu/action-scripts.c:180:2: error: Memory leak: script [memleak]"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "`script` is malloc'd and linked into the global `scripts` list via `list_add(&script->node, &scripts)`. That is the classic embedded list_head pattern, so ownership moves to the global list and nothing leaks. The PR now treats passing the address of an embedded member of the allocation as a use of the owner pointer, which removes this false positive."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz",
    "main criu-4.3/criu/autofs.c:58:2: error: Memory leak: pipe [memleak]"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "autofs_gather_pipe() allocates `pipe` and links it into the global list via list_add_tail(&pipe->list, &autofs_pipes). The global list keeps the allocation, so there is no leak and the main warning was a false positive. The PR treats passing the address of an embedded member to an unknown function as a possible use of the owner, which removes this FP. It is the same pattern as the #6259 test case."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz",
    "main criu-4.3/criu/shmem.c:387:2: error: Memory leak: att [memleak]"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "In the first branch, `att` is allocated and then linked into `si->att` with `list_add(&att->l, &si->att)`. The embedded `l` member is passed by address, so the list now references the allocation and owns it. The memleak at the return was a false positive. The PR treats passing `&ptr->member` to a non-ignored function as a use of `ptr`, which removes this false positive correctly."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz",
    "main criu-4.3/criu/tun.c:134:2: error: Memory leak: tl [memleak]"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "`list_tun_link` allocates `tl` and then calls `list_add_tail(&tl->l, &tun_links)`. That links the embedded list node into the global `tun_links` list, so the allocation is still reachable through the list and is not leaked. The PR treats passing the address of a member of an allocated struct to a non-ignored function as a use of the owner pointer. That removes this false memleak, which is the exact intrusive-list pattern from #6259."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz",
    "main criu-4.3/plugins/amdgpu/amdgpu_plugin_dmabuf.c:173:3: error: Memory leak: b [memleak]"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "The allocated `b` is linked into the global `dmabuf_list` via `list_add(&b->node, &dmabuf_list)`, which is an intrusive list. Later, `try_dump_dmabuf_list` walks that list and frees the entries. Ownership is therefore transferred, so the memleak warning was a false positive. The PR treats passing the address of an embedded member to a function as a use of the owner, which removes it."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz",
    "main criu-4.3/plugins/amdgpu/amdgpu_plugin_util.c:164:2: error: Memory leak: work [memleak]"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "`work` is malloc'd and its embedded list node `&work->l` is passed to `list_add()`, which links it into the global `completed_work` list. `clear_restore_state()` later frees these entries through that list, so the memory is not leaked. The old memleak report was a false positive, and the PR removes it by treating the passed member address as a use of `work`."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz",
    "main criu-4.3/plugins/amdgpu/amdgpu_plugin_util.c:67:2: error: Memory leak: st [memleak]"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "`st` is allocated, and then `list_add(&st->l, &dumped_fds)` links its embedded list node into a global list. The memory stays reachable through that list, which is the classic intrusive-list pattern from #6259, so it is not leaked. The PR now treats passing the address of an embedded member to a non-leak-ignore function as a use of the owner, which removes this false positive."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz",
    "main criu-4.3/plugins/cuda/cuda_plugin_cli.c:101:2: error: Memory leak: new [memleak]"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "`new` is allocated with xmalloc. Its embedded member `&new->list` is then linked into `pid_buf` by `list_add_tail`. After that the memory is reachable through the list, and `dealloc_pid_buffer` frees it later. So the memleak warning was a false positive. The PR now treats passing the address of an embedded member to a function as a use of the owner pointer, which removes this false positive."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz",
    "main criu-4.3/plugins/cuda/cuda_plugin_driver.c:112:2: error: Memory leak: info [memleak]"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "`info` is allocated and then added to the global `cuda_pids` list with `list_add_tail(&info->list, &cuda_pids)`. The embedded list node points into the allocation, so the list now owns the memory and `free_cuda_pid_list()` frees it later. The old memleak report was a false positive. The PR treats passing the address of an embedded member as a use of the owning pointer, which removes it correctly."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz",
    "main criu-4.3/test/zdtm/transition/maps007.c:69:3: error: Memory leak: shm [memleak]"
   ],
   "verdict": {
    "verdict": "acceptable regression",
    "confidence": "medium",
    "explanation": "`shm` is mmap'd at line 49 and never munmap'd. The early `return 1` at line 69 leaves the mapping in place, so main's warning was technically a true positive, though harmless because it is in main. The PR now treats `futex_set(&shm->delta, v)` as a possible ownership transfer because a member address is passed to a function it does not know. `futex_set` only stores a value into the futex and does not keep the pointer. The removed warning is therefore a new false negative caused by the conservative heuristic."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/libn/libnl3/libnl3_3.12.0.orig.tar.gz",
    "main libnl-3.12.0/lib/genl/family.c:371:2: error: Memory leak: op [memleak]"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "`op` is allocated with calloc, and then `nl_list_add_tail(&op->o_list, &family->gf_ops)` links its embedded list node into the family's list. That is the intrusive-list ownership pattern, so the memory is still reachable through `family->gf_ops` and is freed later. Main's memleak warning at line 371 is a false positive. The PR treats passing the address of an embedded member to a non-ignored function as possible use of the owner, which removes it."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/libn/libnl3/libnl3_3.12.0.orig.tar.gz",
    "main libnl-3.12.0/lib/genl/family.c:392:2: error: Memory leak: grp [memleak]"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "The code passes `&grp->list`, the address of an embedded list node, to `nl_list_add_tail()`, which links it into `family->gf_mc_grps`. That list now owns the allocation, so `grp` is not leaked. The old memleak warning was a false positive, and the PR removes it by treating the member address as a use of `grp`."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/o/otf/otf_1.12.5+dfsg.orig.tar.gz",
    "main otf-1.12.5+dfsg/otfauxlib/OTFAUX_Process.c:424:5: error: Memory leak: recv [memleak]"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "The function callocs `recv` and links it into a queue with `stack_add(&queue->receives, &recv->e)`. This is an intrusive list: `e` is embedded storage inside the allocation, so the queue keeps the memory reachable and it can be recovered later (container_of-style). Ownership is transferred, so the memleak warning was a false positive. The PR now treats passing `&recv->e` to a non-ignored function as possible use of `recv`, which removes it."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/s/seatd/seatd_0.9.3.orig.tar.gz",
    "main seatd-0.9.3/libseat/backend/seatd.c:197:2: error: Memory leak: ev [memleak]"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "queue_event allocates ev and passes &ev->link to linked_list_insert, which links it into backend->pending_events. Ownership moves to the list, and execute_events later frees the entries. The old memleak warning was a false positive. The PR now treats passing the address of an embedded member as a possible use of the owner, which removes it."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/t/tarantool/tarantool_2.6.0.orig.tar.gz",
    "main tarantool_2.6.0/test/unit/cbus_stress.c:252:1: error: Memory leak: msg [memleak]"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "`msg` is malloc'ed and `&msg->cmsg` is passed to `cpipe_push`, which queues the embedded member. The message is later freed in `thread_msg_received_cb` through `container_of`. So ownership is handed over through the address of an embedded member, and the memleak warning was a false positive. The PR now treats `&msg->cmsg` passed to a non-ignored function as a possible use of `msg`, which removes the false positive."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/t/tarantool/tarantool_2.6.0.orig.tar.gz",
    "main tarantool_2.6.0/test/unit/swim_test_ev.c:225:1: error: Memory leak: e [memleak]"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "`e` is malloc'd and `&e->base` is passed to `swim_event_create()`, which registers the event; the later delete callback frees it. `e` is also stored in `events_hash` through `node`. The memory is not leaked, so the old memleak warning was a false positive. The PR treats passing the address of an embedded member as a possible use of the owning allocation, which removes it."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/u/ulogd2/ulogd2_2.0.9.orig.tar.xz",
    "main ulogd-2.0.9/src/ulogd.c:787:2: error: Memory leak: ph [memleak]"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "`load_plugin()` callocs `ph` and then calls `llist_add(&ph->list, &ulogd_plugins_handle)`. This links the embedded list node into a global list, so the allocation stays reachable and is not leaked. This is exactly the #6259 pattern the PR targets. Removing the false memleak warning is an improvement."
   }
  },
  {
   "key": [
    "https://ftp.debian.org/debian/pool/main/u/ulogd2/ulogd2_2.0.9.orig.tar.xz",
    "main ulogd-2.0.9/util/db.c:453:2: error: Memory leak: query [memleak]"
   ],
   "verdict": {
    "verdict": "improvement",
    "confidence": "high",
    "explanation": "`llist_add_tail(&query->list, &di->backlog)` inserts the embedded list node of the freshly allocated `query` into the backlog list. That transfers ownership: the memory can be reached through the list and is freed later, e.g. in `__treat_backlog`. The old memleak warning at `return 0;` was a false positive. The PR now treats passing the address of a member embedded in the allocation as a use of `p`, so the false positive is gone."
   }
  }
 ],
 "started": "2026-11-04 08:21:14 UTC",
 "runner": "pc"
}