[bug] Windows: user-reported stop during two large overlapping raids #122
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
🤖 Filed by Codex, AI-агент chexit.
Пользователь сообщает, что при двух больших налётах AirDef часто перестаёт работать, без заметного обвала FPS перед этим. На RTX 3060 + Ryzen 5600X во время налёта около 50 FPS. Точный build, режим эффектов и отличие отключения мода от падения всего процесса пока не подтверждены; запрошены строки Windows latest.log.
Что проверено: нативные два перекрывающихся меню-пресета «Массированный удар» с ответами плоского мира и встроенной записью; два налёта 40+40 «Орешников» с разделением и окончанием записи. На настоящем WASM с flat render replies: 64 ПВО, два принятых налёта 40+40, 184 цели в воздухе на тике 2102, 271 шаг, переход на HD+grid. Прогон прошёл без остановки. Это не GPU-тест и не воспроизведение на Windows; причина вылета и исправление причины не заявлены.
Исправлен пробел стенда #102: прежний второй заказ отклонялся во время планирования, а отсутствие render replies оставляло пуски в ожидании земли. Новая фикстура проверяет принятие заказов и обслуживаемую геометрию, report отличает requested count, проверенную точку во времени и неизвестный peak.
Движок ed7615d36 содержит диагностику mod ID/callback/fuel budget/remaining/full error chain; лимиты не увеличивались. Тест с настоящим WASM fuel trap подтверждает остановку только нарушившего мода. У AirDef нет собственной реализации frame hook: основная работа идёт в tick/command/UI; 10M frame budget нельзя автоматически объявлять причиной.
Нужно для следующего воспроизведения: build-identity.json, Windows latest.log с моментом остановки, состав/размер двух налётов, HD/обычные эффекты и открытые monitor/grid/replay. Раздельно установить OutOfFuel, allocation/trap, ошибку host/render или падение процесса; затем добавить regression именно причины. FPS требует отдельного CPU/GPU-замера и не объявляется улучшенным этим расследованием.
Связано: #102, #88, #89. Issues не закрывать автоматически.
🤖 Agent: Codex, with GPT-6.1 Terra and GPT-6 Luna.
Опубликовано до10f24b5: engineed7615d36 с mod ID/callback/fuel budget/remaining/full error chain; actual Wasmtime fuel-trap regression прошёл. AirDef runtime limits не повышались. Native true-overlap тесты двух стандартных массовых пресетов и двух волн с разделением/записью прошли. Default actual WASM stress теперь обслуживает flat ground/sections/rays:64 ПВО, два принятых приказа40+40 Орешников, HD+grid,184 цели в воздухе на тике2102,271 шаг PASS. Лёгкий26-шаговый тест также прошёл.
Пользовательский Windows-вылет пока НЕ воспроизведён и исправлением причины не объявляется. У AirDef нет собственной frame-hook реализации, поэтому общий frame fuel10M сам по себе не диагноз. Нужны исходный latest.log/build identity и сведения, закрывается процесс целиком или останавливается только мод. FPS на RTX3060/5600X не измерялся и не обещается улучшенным. Сценарии, данные и следующий шаг.
Issue state intentionally unchanged.
🤖 Agent: Codex, with GPT-6.1 Terra and GPT-6 Luna.
Reproduced and fixed one concrete mod-only fuel exhaustion failure (production fix 1f28f83; evidence/docs
d410e2c). Diagnostic guest uses exactly the maximum menu composition: two accepted raids of 11 kinds × 40, 64 SAMs, answered flat render terrain, HD + grid + recording. Before: tick 1835 exhausted all 300,000,000 fuel and stopped AirDef. Cause: each blast invalidated the ground cache by scanning every cached cell. Fix removes only coordinates in the affected rectangle; no fuel cap, raid limit, or visual feature was changed. After: 421 steps / 3602 ticks passed, peak tick fuel 135,273,690/300M, zero failed callbacks. Reported combat/world counters before the failure point match; this is not a proof of equality of every hidden state field.Scenario, trigger patch, logs and hashes. The trigger patch exists only in the diagnostic guest, not production. This establishes a reproduced failure class and its fix; without the user's original Windows log we cannot assert it was the same failure. GPU/FPS not measured. Current production regression also passed: actual WASM flat scenario 271 steps and light scenario 27 steps. Issue remains open for Windows acceptance.
🤖 Agent: Kimi Code, с участием Kimi for Coding.
Опубликовано в
kimi-workкакd45629ae2.По присланному Windows-логу воспроизведён именно UI-путь
known_units ← order_raid ← launch_wave ← ui_select: на каждом дроне заново вычислялся снимок известных комплексов, а сам снимок пересканировал журнал и dedup-список. Это отдельный класс от прежнего tick height-cache сбоя.Исправление: один
known_unitssnapshot на приказ, передаётся в radar strikes/choose_target; снимок стал O(журнал + группировка) через множества.price_grid_onпереиспользует свой снимок. Лимиты, размер волны, HD, запись и семантика разведки/выбора носителей не менялись.До: второй приказ 111 дронов при 13172 записях и 144 живых комплексах исчерпал ровно 1e9 fuel. После: тот же диагностический сценарий — max command 32946177/1e9, ошибок 0;
/statsпобайтово совпал. Замеры и trigger.На интегрированной ветке: core release 197 + 8 сценариев (8 ignored), adapter 66 + 1 boundary + 5 сценариев; лёгкий WASM 30 шагов; тяжёлый WASM 283 шага, command max 6939810/1e9, tick max 182781385/300M, failures=0.
Windows GUI-приёмка остаётся за пользователем: нужно повторить второй крупный налёт на этом коммите. Issue оставляю открытым.
🤖 Agent: Kimi Code.
По новому Windows-логу исправлен отдельный OOM в
Recording::note_sams, коммит367c7f4acвkimi-work.До исправления полная запись 64 вращающихся РЛС создавала 384000
SamKey— 27 MiB только в ключах; активная запись и три сохранённых реплея превышали лимит WASM 64 MiB. Теперь действует общий бюджет 32768 ключей: при давлении старые позы прореживаются, ёмкость освобождается, следующие samples становятся реже; первая/последняя позы сохраняются, запись не замораживается.Проверки: core release 233 + 8 сценариев (8 ignored), adapter 68 + 1 boundary + 5 сценариев, WASM contract 30 шагов. Длинный реальный WASM-стресс: 64 РЛС, 60 волн по 4 Shahed, 24002 тика/два полных окна записи, 185 шагов; max tick fuel 137346889/300M, failures=0. Лимиты не увеличивались.
Подробности: RAID-STABILITY.md. Issue остаётся открытым для приёмки на Windows; GPU/FPS этот тест не измеряет.