Re: Issue with my patch to add ARM-uclibc support to LuaCoco

["Zachary P. Landau" <kapheine@...>]

> Oh, nice! Be sure to send it to me when it's finished. I'll
> probably release an upgrade to Coco soon, so it patches cleanly
> against Lua 5.1.2 (otherwise no functional changes).

No problem.  I'll send it along once I work this issue out.

> Do you create any coros from C? You need to use lua_newcthread()
> and not lua_newthread().

No, I don't.  I even verified this within the code, to report to me if
anyone other than coco itself called newthread, and nobody does.

> Err, that function returns the _default_ stacksize for newly
> created coros (and not any info about a particular coro).

Whoops, so it does.

> > So at this point it thinks it is a coco coroutine as well.  But when
> > the code gets to luai_userstateyield() in lua_yield(), the LHASCOCO
> > macro returns false and so we try to do a non-coco yield instead.
>
> Well, that part of the code is a one-liner. So I don't think it's
> the culprit. Either the coroutine does not have a C stack to
> begin with (see above) or the particular field holding the status
> has been corrupted (trace modifications to it with a debugger).

[snip]

> Note that it may be easier (and more portable across library
> versions) to add some inline assembler code than patching
> setjmp() buffers. See the x86 and the MIPS entries.

I took your advice on this and wrote a version using inline assembler
instead.  Once I got that working, the same issue showed up.  That is,
at some point L at the end of the stack comes back as 0.  The fact
that both my setjmp and assembler versions both show the same error
probably tells me something significant.  I'm just too burned out
today to process what it is.  I'll get back on that tomorrow.

Some possibly interesting helpful I learned while debugging:

* I verified that I am always creating a C stack, and that L and
coco_State are always setup properly at that point
* Up until the point where L points to 0, L is always the correct
value.  That is, there doesn't seem to be any sort of corruption of
the L value (at least not until the end)
* The problem always shows up during the same two calls to yield: the
calls in copas.lua in the send function.  I'm not sure if/how these
are different.  I am going to try to get together a demo and see if I
can get that to fail in the same way.

Looking through the generated luaCOCO_resume and luaCOCO_yield code, I
don't see any obvious things that would cause corruption.  The first
time I notice L pointing to 0 is when we jump back to the
luaCOCO_resume function.  But jumping back to luaCOCO_resume USUALLY
works, just not in this weird case.

Anyway, I spent most of my time just getting the assembler
implementation done, so I haven't yet spent a whole lot of time
debugging it.  I'm mostly emailed you in case my recent finds help you
spot an obvious problem.

Thanks for your suggestions, they've been helpful.

--
Zachary P. Landau <kapheine@gmail.com>