[Openmcl-devel] ARM testing

[Gary Byers]

It seems to be confused about where the initial thread's stack's bounds are.
Marking things (setting a bit to indicate that an object is reachable and
shouldn't be GCed) is conceptually recursive: to mark a CONS, you set a
bit to indicate that the cons cell is reachable, then mark the car and cdr
in some order.  If this is implemented as straightforward recursion, it'd
require stack space proportional to the "height" of the object being marked
(a long list is a tall tree of conses.)

The recursive marker (the C function "rmark") in CCL is supposed to
check available stack space on each invokation.  If there's enough, it
just recurses in the obvious way; if not, it switches to a
link-inverting algorithm that's a bit slower but runs in bounded stack
space.  The backtrace seems so show rmark() merrily recursing away until
the stack overflows, which suggests that its notion of how much stack
space is available is incorrect.

In the kernel debugger, the 'm' command will show the bounds of various
heap and stack memory areas that the lisp knows about.  If you get a chance,
could you provoke the crash and look at the bounds of the 'cstack' area ?
There'll be only one of them, and the address that's generating the fault
should be in that area and near the lower bound.  Is it ?


On Fri, 21 Jan 2011, David Brown wrote:

> On Thu, Jan 20 2011, Gary Byers wrote:
>
>> On Thu, 20 Jan 2011, David Brown wrote:
>
>> I don't have a good guess as to what would be causing excessive (but bounded)
>> stack usage.
>
> Here's a stack dump when the stack fills:
>
>  http://pastebin.com/V5Q3uBgd
>
> I'm not sure this really says much, other than there being a really long
> list somewhere.
>
> David
>
>