|
|
Infologs, unfortunately, aren't of much help in case of this bug; it indeed seems to be memory corruption of some kind. Your replay, OTOH, will be most useful, since it more or less reliably reproduces one instance of this crash. What's needed now is adding some quite extensive logging and checking where and when exactly the bug happens. |
|
|
|
The attached demo was from one of the crashed games - unfortunately the other crashed game had no demo at all, and this one seems to be corrupt/broken... :-( |
|
|
|
Can we start adding some tracing & logging into luaui to trace back the callers of the functions containing the broken ipairs() calls? If we can log this stuff out to a file maybe we can trace back to where the error first entered LuaUI? I'm only guessing, I don't know enough about LuaUI to be able to know what the problem might be, but if we can trace it back to a point where we know the error is about to happen in LuaUI, then maybe we can trigger Spring to dump core/other info in a nicer way and reveal some more info about the C state...? |
|
|
|
To clarify "Can we start adding some tracing & logging into luaui", I mean tracing type code into the LuaUI .lua code itself (eg the widgets.lua file etc) |
|
|
|
adding tracing is always possible, I'll try to hack something up. |
|
|
|
I'd be happy to have a go at it myself, but I need is a function or 2 I can call to log info to a logfile somewhere, rather than to the spring console... |
|
|
|
spring console gets logged into the infolog, so no problem here. use LogOutput as usual. |
|
|
|
Yes but then I will get my spring console spammed with random debugging crap. Since I want to be able to play normal games while I wait for the errors to happen, this isn't a good solution... |
|
|
|
oh, in this case, simply create a global logging output stream (e.g. fstream) and use this instead of log output. pretty simple. |
|
|
|
/me goes to Lua tutorial website :-) |
|
|
|
i was talking about c++ side :>
anyways, some remotely good news: the bug occurs in spring built by gcc 4.3 and crashes in free(), so it's most likely a dangling pointer/memory corruption thing. |
|
|
|
So can it be reproduced in a debug build? If you know what game/sim frame the replay crashes on, can you make a special build with a breakpoint at the start of that frame? |
|
|
|
that's the plan. i'm 99% sure it's a double free problem. |
|
|
|
Although the demo isn't really long enough to say for certain, the infologs strongly hint that this is the same issue as http://spring.clan-sy.com/mantis/view.php?id=889 . Closing this one because it can't be reproduced and now very likely fixed. |
|
