Mark H Weaver <m...@netris.org> skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Mark H Weaver <m...@netris.org> skribis: >> >>> Hi Ludovic, >>> >>>> The problem here is that, when the second overflow occurs, that reserve >>>> has already been used, so it just aborts. >>>> >>>> Commit 70057f3 in ‘stable-2.0’ fixes that (will be in 2.0.10.) >>> >>> Thanks for fixing this, but there's still a slight problem. After a VM >>> overflow is caught and the user is left in the debugger, typing ",q" >>> sometimes causes another stack overflow. > [...] > >> The second overflow occurs because the stack reserve is reinstated >> before the handler is invoked, so the handler doesn’t have enough stack >> space to run: > > [...] > >> I tried using a making the ‘quit’ handler in repl.scm a pre-unwind >> handler but that doesn’t help. Ideas? > > I think we need two different stack reserves: one that's used normally, > and another smaller one that's used within the debugger after a stack > overflow. It should be possible to do some minor debugging after a > stack overflow: enough to see where the overflow happened and maybe look > at some stack frames to investigate why it happened.
That already works: one can use ,bt, ,frame, ,locals, etc. It’s just that there’s this weird-looking phenomenon when typing ,q. Ludo’.
