AI review of 2026-09-24_13-19-35-264fe9687932-results.txt PR: #8891 https://github.com/cppcheck-opensource/cppcheck/pull/8891 Tested: 264fe96879326ae24e519ce5661e7b6621ff8c66 Merge base: 8bb772daa62d60900b0e48535063f902aed45e41 Reviewed: 2026-11-04 11:23:50 UTC Model: claude-opus-5-5 (effort high) Results: 18 reviewed of 18 in the report Verdicts: 1 acceptable regression, 17 improvement Tokens: 27921 input, 116752 cache read, 14594 cache write, 3583 output The verdicts are written by AI and can be wrong. ---- 1 / 18 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz Result: main criu-4.3/criu/action-scripts.c:180:2: error: Memory leak: script [memleak] 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. ---- 2 / 18 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz Result: main criu-4.3/criu/autofs.c:58:2: error: Memory leak: pipe [memleak] 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. ---- 3 / 18 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz Result: main criu-4.3/criu/shmem.c:387:2: error: Memory leak: att [memleak] 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. ---- 4 / 18 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz Result: main criu-4.3/criu/tun.c:134:2: error: Memory leak: tl [memleak] 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. ---- 5 / 18 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz Result: main criu-4.3/plugins/amdgpu/amdgpu_plugin_dmabuf.c:173:3: error: Memory leak: b [memleak] 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. ---- 6 / 18 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz Result: main criu-4.3/plugins/amdgpu/amdgpu_plugin_util.c:164:2: error: Memory leak: work [memleak] 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`. ---- 7 / 18 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz Result: main criu-4.3/plugins/amdgpu/amdgpu_plugin_util.c:67:2: error: Memory leak: st [memleak] 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. ---- 8 / 18 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz Result: main criu-4.3/plugins/cuda/cuda_plugin_cli.c:101:2: error: Memory leak: new [memleak] 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. ---- 9 / 18 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz Result: main criu-4.3/plugins/cuda/cuda_plugin_driver.c:112:2: error: Memory leak: info [memleak] 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. ---- 10 / 18 ---- Verdict: ACCEPTABLE REGRESSION (medium confidence) Package: https://ftp.debian.org/debian/pool/main/c/criu/criu_4.3.orig.tar.xz Result: main criu-4.3/test/zdtm/transition/maps007.c:69:3: error: Memory leak: shm [memleak] 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. ---- 11 / 18 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/libn/libnl3/libnl3_3.12.0.orig.tar.gz Result: main libnl-3.12.0/lib/genl/family.c:371:2: error: Memory leak: op [memleak] 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. ---- 12 / 18 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/libn/libnl3/libnl3_3.12.0.orig.tar.gz Result: main libnl-3.12.0/lib/genl/family.c:392:2: error: Memory leak: grp [memleak] 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`. ---- 13 / 18 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/o/otf/otf_1.12.5+dfsg.orig.tar.gz Result: main otf-1.12.5+dfsg/otfauxlib/OTFAUX_Process.c:424:5: error: Memory leak: recv [memleak] 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. ---- 14 / 18 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/s/seatd/seatd_0.9.3.orig.tar.gz Result: main seatd-0.9.3/libseat/backend/seatd.c:197:2: error: Memory leak: ev [memleak] 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. ---- 15 / 18 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/t/tarantool/tarantool_2.6.0.orig.tar.gz Result: main tarantool_2.6.0/test/unit/cbus_stress.c:252:1: error: Memory leak: msg [memleak] 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. ---- 16 / 18 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/t/tarantool/tarantool_2.6.0.orig.tar.gz Result: main tarantool_2.6.0/test/unit/swim_test_ev.c:225:1: error: Memory leak: e [memleak] 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. ---- 17 / 18 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/u/ulogd2/ulogd2_2.0.9.orig.tar.xz Result: main ulogd-2.0.9/src/ulogd.c:787:2: error: Memory leak: ph [memleak] 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. ---- 18 / 18 ---- Verdict: IMPROVEMENT (high confidence) Package: https://ftp.debian.org/debian/pool/main/u/ulogd2/ulogd2_2.0.9.orig.tar.xz Result: main ulogd-2.0.9/util/db.c:453:2: error: Memory leak: query [memleak] 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.