[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A stack overflow problem.
From: |
Ludovic Courtès |
Subject: |
Re: A stack overflow problem. |
Date: |
Fri, 06 Dec 2013 18:57:02 +0100 |
User-agent: |
Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux) |
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’.