Native V8 array-length crash during active tool-heavy turns and session resume
- Linguagem predominante
- Shell
- Estrelas
- 11.2k
- Forks
- 1.9k
- Merge médio
- 14h 16min
- PRs com merge (30d)
- 6
Descrição
### Describe the bug
The packaged Linux x64 native binary aborts inside V8 during active, tool-heavy turns as well as while resuming conversations.
The original report attributed this to several concurrent resumes. Further testing disproved that: Herdr automatic restoration was disabled, failed panes were cleared, and an already-running conversation crashed mid-turn while displaying:
```text
Reviewing brief clarity · 29.4 KiB
# Fatal error in , line 0
# Fatal JavaScript invalid array length 0
```
A second active conversation failed similarly while displaying `Shipping Lakebase refactor · 53.7 KiB`. Both ended with SIGILL. These were normal active turns, not startup or bulk restore.
The fatal string maps to V8's `Accessors::ArrayLengthSetter`, where `JSArray::SetLength(..., 0)` returned an exception and V8 called `FATAL`:
https://github.com/v8/v8/blob/main/src/builtins/accessors.cc#L210-L214
### Affected version
GitHub Copilot CLI 1.0.70
### Steps to reproduce the behavior
A minimal deterministic reproduction is not yet available. The recurring observed sequence is:
1. Start or resume a Copilot conversation.
2. Run a long, tool-heavy workflow with many subagents.
3. Start another turn.
4. While Copilot is actively streaming/reviewing the response, the native process aborts with `Fatal JavaScript invalid array length 0` and SIGILL.
Two affected conversation histories were approximately:
- 14.1 MB / 2,482 events / 929 completed tool calls / 23 completed subagents
- 21.3 MB / 3,959 events / approximately 1,500 completed tool calls / 24 started subagents
The final persisted event in each is `assistant.turn_start` without a matching `assistant.turn_end`, confirming the failure occurred mid-turn.
### Expected behavior
Long or tool-heavy conversations should continue normally. If an internal array operation fails, the CLI should surface a recoverable JavaScript error rather than aborting the native process.
### Additional context
- OS: Ubuntu 24.04 under WSL2, Linux `6.6.114.1-microsoft-standard-WSL2`, x86_64
- Terminal: Windows Terminal -> Herdr PTYs
- Shell: zsh
- Memory after the latest crash: 31 GiB total, 28 GiB available, no swap in use
- Copilot's embedded runtime reports Node.js `v24.16.0`
- Kernel logs show repeated SIGILL failures at the same native address
- `app.js` and `index.js` checksums match between the npm platform package and Copilot's update cache
- The npm loader's subsequent `no platform package found` message is misleading; the platform package launched successfully and its child process terminated by signal
- Reinstalling npm replaces 1.0.70 with the same 1.0.70 and does not resolve the failure
- Herdr's `resume_agents_on_restore` setting is not required to trigger this
- Running the packaged JavaScript entrypoint under system Node.js `v24.11.1` passes startup/version and interactive Herdr smoke tests. I am testing this as a temporary workaround, but it has not yet had the same long-duration workload.
Guia de contribuição
Direção de pesquisa
Comece pelos pontos de entrada JavaScript empacotados app.js e index.js e, em seguida, compare o comportamento deles sob o workaround documentado do sistema Node.js. Reproduza, se possível, o workflow longo e com uso intenso de ferramentas de um turno ativo e capture a falha nativa. Considera-se concluído quando a carga de trabalho não for mais abortada com o V8 invalid-array-length SIGILL ou quando a CLI apresentar um erro recuperável em vez disso.
Escrita pelo modelo de indexação a partir do texto da issue.
Avaliação
- Stack de tecnologia
- javascript, node.js
- Domínio
- cli
- Tipo de issue
- Bug
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Status de atividade
- Pouca atividade
- Clareza
- Precisa de esclarecimento
- Facilidade para iniciantes
- 25/100