lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Dmitriy Iassenev wrote:
> MP> Well, but what happens? An error or a crash?
> access violation on lua_resume call, because lua_state, associated with
> the thread, is invalid. using debug memory allocator (which fills freed
> data with 'C'), I found, that lua_State, returned by lua_newcthread,
> is just freed during garbage collection, i.e. thread is collected

LuaJIT doesn't change anything in the garbage collector. And
there are now known bugs left in the Lua 5.1 garbage collector.
So the reference to the thread somehow must have gotten lost or
overwritten. Can you check that registry[ref] still contains
the same thread object before you resume it?

[BTW to Roberto: it might be useful to add an assertion to
lua_resume to check whether the resumed thread is a thread object
and is still alive.]

>                 m_state                = lua_newcthread(L,0);
>                 VERIFY2                (m_state,"Cannot create new Lua thread");

The second line will never be executed because lua_newcthread
always returns a valid state. It throws a memory error in case it
runs out of space (just like lua_newthread). Maybe this happens
and you are not seeing the error because it's caught by a pcall
or resume. But that wouldn't explain the problem ...

BTW: How many threads are you creating? If you have hundreds or
thousands you might want to reduce the STACKSIZE in the .def file
for the executable. Because the default of 1 MB is the effective
minimum for CreateFiber(). Otherwise you may hit the system total
commit limit for Windows. See:

> I am sure I have troubles because of the reference, since if I leave
> thread in the lua stack all works fine. I used references before in
> Lua 5.02 and all worked correct.

I've looked at the Lua 5.1 ref/unref implementation and I don't
see anything wrong. Only the lua_objlen() call might go wrong
when unrelated numeric keys are stored in the registry (but the
Lua 5.0 manual already warned about this).

You might want to dump all integer keys in the registry and their
values at strategic points. Or try to use an extra table instead
of the registry for holding the threads (and dump this one).