Re: A stack overflow problem.

[Ludovic Courtès]

Mark H Weaver <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> Mark H Weaver <address@hidden> 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’.