## Memory Allocation Defects (High)

### Trigger Signals

- Same pointer `free`/`delete`/`drop` multiple times (double free)
- Memory allocated by `malloc`/`new` not freed on some code paths
- `malloc`/`free` mixed with `new`/`delete`
- `realloc` without updating all variables holding the old pointer

### Judgment Process

1. **Identify allocation-free pairs**: `find_references` tracks pointer variables allocated by `malloc`/`calloc`/`new`, marking all `free`/`delete` calls
2. **Check pairing completeness**: `Read` extracts all exit paths of the function (return, throw, goto), confirming that allocated memory has corresponding free on each path:
   - Normal path: is there free/delete
   - Exception path (catch/throw): is there free/delete
   - Early return: is there free/delete
3. **Check nulling after free**: `Read` confirms whether the pointer is set to null after `free`/`delete` (preventing double free and use-after-free)
4. **Check allocation/free matching**: `Read` confirms `malloc` corresponds to `free`, `new` corresponds to `delete`, `new[]` corresponds to `delete[]`, without cross-mixing
5. **Check realloc updates**: `Read` confirms whether all variables holding the old pointer are updated to the new pointer after `realloc`

### Evidence Construction

After confirming a defect, the output must include:
- Allocation point (memory allocation location, with file:line number)
- Missing free path (which exit path omitted the free)
- Specific location of allocation/free mismatch (e.g., malloc + delete)
- Business impact (continuous memory growth leading to OOM, double free causing heap corruption)

### Exclusions

- Using RAII/smart pointers (`unique_ptr`/`shared_ptr`/`Box`/`Vec`) for automatic management
- Internal implementations of memory pools/custom allocators (guaranteed by the allocator itself)
- Short-lived programs (command-line tools, OS reclaims after process exit)
- Rust safe code (ownership system guarantee)
