[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Debugging crashes on GC
- From: "Alexander Gladysh" <agladysh@...>
- Date: Wed, 26 Jul 2006 18:10:11 +0400
> I've assigned this coroutine to global Lua variable. The
> crashes are still here.
> Is there any method to debug GC crashes except that trying to
> randomly guess which Lua object got collected?
I am hardly an expert on this, but if it is userdata you suspect then
what I do is make sure all userdata objects have a __gc function
registered in their metatable. Then from that function I print a log
message reporting the address of the object getting collected. I match
this to messages logged when the userdata object is created. I have
found this to help with both problems of objects getting collected when
I don't want them to and the issue of making sure objects are collected
when they should be.
That's a good idea, thank you. But unfortunately all my userdata
objects are Luabind objects. They seem to have their own __gc
Unfortunately I don't know of a way to track the lifecycle of lua
objects other than userdata.
I think it is possible to set __gc metamethod to table objects from
Lua, and I've read somewhere that you can set metatable to any Lua
data type from C. Can't say if __gc would get called in the case with,
say, numbers though... but we'd need to inspect thread collection, not
If you can modify the lua source in your
project it might be possible to change the garbage collection code to
report some information on objects as they get collected.
Yes, we can modify Lua sources in our project (can't say that we eager
to do so).
I do not think that it is userdata (not the visible side of problem
anyway). Since rawgeti gets corrupted Lua state as parameter, it looks
like that it is some Lua thread (coroutine) gets collected. Have I do
hack Lua sources to add logging on construction/collection of all Lua
threads, or I can track it interactively in VC 8 debugger somehow?