问题 / #3045

#3045 [Bug]: PleReader initialization failures can wait forever for nonexistent reads

open · @j-luwierski · 0 评论 · 去 GitHub 看

Linux

说明

### What happened

`PleReader::open()` can hang in its error cleanup before any read has been submitted. Two CPU-only reproductions on freshly fetched upstream main `477ac13cbe8e582c20484871ce459d20d82df09d`:

1. Make `DirectFile::alloc_aligned()` return null by wrapping `posix_memalign` to return `ENOMEM`. `open()` sets `max_inflight` before allocating the slab, then calls `close()` on failure. The free-slot vector is still empty, so `close()` waits indefinitely in `file.wait(..., -1)`. The expected `cannot allocate read buffers` error never returns.
2. Successfully open a reader, close it, then open the same valid file with a table range extending beyond EOF. `close()` cleared the free slots but retained the previous `max_inflight`; the second open reaches the bounds error and hangs in cleanup. Calling `open()` directly on an already open reader has the same problem because it closes first.

Expected: return false with the existing error, close the file, permit repeated close and a later valid open/read.

### Strata version, GPU, OS

Latest upstream main checked directly against Niko1221/Strata: `477ac13c` (0.1.45). Linux x86_64, GCC 14.2.0. Synthetic 16 KiB file and real DirectFile I/O; no GPU or model weights.

### Engine log

The lifecycle regression was compiled against unchanged upstream source and run with a two-second subprocess timeout:

```text
reads caller exit 0
reads threaded exit 0
reopen caller TIMEOUT after 2 seconds
reopen threaded TIMEOUT after 2 seconds
alloc caller TIMEOUT after 2 seconds
alloc threaded TIMEOUT after 2 seconds
```

These are deterministic API/error-path reproductions, not a claim that ordinary model loading exhausts memory. The proposed change delays publishing the slot count until initialization completes and resets it on close.

Searched open issues and PRs for PleReader, initialization, allocation and close. Related #2991 concerns colliding temporary files in a different selftest; #2623 concerns prefetch matching. Neither covers this initialization bookkeeping.

本站相关内容

相关页面的快捷入口。