REPL overlays are not loaded when doing `:st` in `nix-eval`-spawned debugger #1212

New issue

Open

opened 2026-05-07 16:13:29 +00:00 by blokyk · 1 comment

blokyk commented

2026-05-07 16:13:29 +00:00

Member

Describe the bug

When using nix eval --debugger, REPL overlays are not loaded after an :st command (but are after e.g. :s). This specifically doesn't happen when trying to do the same using nix repl --debugger.

Steps To Reproduce

$ echo 'info: final: prev: { test = "meow"; }' > test-overlay.nix
$ nix eval --impure -E 'let f = v: throw "oopsie"; in f 4'  --debugger --repl-overlays $PWD/test-overlay.nix
error: oopsie

Added 2 variables.
Lix 2.96.0-devpre20260504-dev_6b2979e debugger
Type :? for help.
Loading 'repl-overlays'...
Added 3 variables.
nix-repl> test
"meow"

nix-repl> :st

0: error: oopsie
«string»:1:12

     1| let f = v: throw "oopsie"; in f 4
      |            ^

Env level 0
static: v 

Env level 1
static: f 

Env level 2
abort baseNameOf break builtins derivation derivationStrict dirOf false fetchGit fetchMercurial fetchTarball fetchTree fromTOML import isNull map null placeholder removeAttrs scopedImport throw toString true 

Added 2 variables.

nix-repl> test
error: undefined variable 'test'
       at «string»:1:1:
            1| test
             | ^

(This also happens if you change stack frame btw)

Expected behavior

The REPL overlays get reloaded and added to the lexical scope each time (or maybe don't get reloaded if we didn't change frame, but stay in scope).

`nix --version` output

nix (Lix, like Nix) 2.96.0-devpre20260504-dev_6b2979e
System type: x86_64-linux
Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux
Features: gc, signed-caches
System configuration file: /etc/nix/nix.conf
User configuration files: /home/courvoie/.config/nix/nix.conf:/etc/xdg/xdg-ubuntu-xorg/nix/nix.conf:/etc/xdg/nix/nix.conf
Store directory: /nix/store
State directory: /nix/var/nix
Data directory: /home/courvoie/lix/outputs/out/share

This also happens on Lix 2.95.3

Additional context

Since this doesn't happen when used directly from the repl, this might be related to #777? Just guessing, I haven't looked at the stackframe-changing code (nor the stepping one), so no idea if that could interfere at all.

## Describe the bug When using `nix eval --debugger`, REPL overlays are not loaded after an `:st` command (but are after e.g. `:s`). This specifically doesn't happen when trying to do the same using `nix repl --debugger`. ## Steps To Reproduce ```sh $ echo 'info: final: prev: { test = "meow"; }' > test-overlay.nix $ nix eval --impure -E 'let f = v: throw "oopsie"; in f 4' --debugger --repl-overlays $PWD/test-overlay.nix error: oopsie Added 2 variables. Lix 2.96.0-devpre20260504-dev_6b2979e debugger Type :? for help. Loading 'repl-overlays'... Added 3 variables. nix-repl> test "meow" nix-repl> :st 0: error: oopsie «string»:1:12 1| let f = v: throw "oopsie"; in f 4 | ^ Env level 0 static: v Env level 1 static: f Env level 2 abort baseNameOf break builtins derivation derivationStrict dirOf false fetchGit fetchMercurial fetchTarball fetchTree fromTOML import isNull map null placeholder removeAttrs scopedImport throw toString true Added 2 variables. nix-repl> test error: undefined variable 'test' at «string»:1:1: 1| test | ^ ``` (This also happens if you change stack frame btw) ## Expected behavior The REPL overlays get reloaded and added to the lexical scope each time (or maybe don't get reloaded if we didn't change frame, but stay in scope). ## `nix --version` output ``` nix (Lix, like Nix) 2.96.0-devpre20260504-dev_6b2979e System type: x86_64-linux Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux Features: gc, signed-caches System configuration file: /etc/nix/nix.conf User configuration files: /home/courvoie/.config/nix/nix.conf:/etc/xdg/xdg-ubuntu-xorg/nix/nix.conf:/etc/xdg/nix/nix.conf Store directory: /nix/store State directory: /nix/var/nix Data directory: /home/courvoie/lix/outputs/out/share ``` This also happens on Lix 2.95.3 ### Additional context Since this doesn't happen when used directly from the repl, this _might_ be related to #777? Just guessing, I haven't looked at the stackframe-changing code (nor the stepping one), so no idea if that could interfere at all.

blokyk added the

Area/repl/debugger

Area/repl

bug

labels

2026-05-07 16:13:29 +00:00

pennae commented

2026-05-19 16:22:49 +00:00

Owner

repl overlays applying in a spawned debugger (rather than a repl started with --debugger) is not well-defined anyway. the debugger executes inside an existing environment stack that cannot be modified without fucking up execution when continuing on from a breakpoint, they can't be loaded globally before starting execution (obviously), and they can't be loaded inside the environment that spawned the debugger and applied as inner layers each time (because not least of all that can easily shadow things, making debugger results dependant on overlay layout)

maybe we should just ignore that setting entirely when spawning a debugger

repl overlays applying in a spawned debugger (rather than a repl started with `--debugger`) is not well-defined anyway. the debugger executes *inside* an existing environment stack that cannot be modified without fucking up execution when continuing on from a breakpoint, they can't be loaded globally before starting execution (obviously), and they can't be loaded inside the environment that spawned the debugger and applied as inner layers each time (because not least of all that can easily shadow things, making debugger results dependant on overlay layout) maybe we should just ignore that setting entirely when spawning a debugger

blokyk referenced this issue

2026-05-29 10:22:20 +00:00

REPL overlays prevent debugger from opening for stack overflows #1220