PDA

View Full Version : Proper use of "unload level" ?



speeder
07-21-2010, 08:00 PM
I am trying to discover two things:

How to reload a level (after the player dies...)

How to unload a level already cleared...

Seemly the function "unload level" causes segfaults... Unloading cleared level ALWAYS segfaulted on me, no matter when I did it, or the active map (dunno why), and I found that unloading the current map and loading it again, like some system scripts do, work to "reload" a map, but this also segfaults randomly, I tried to debug it, but the debugger could not track properly what happened (ie: I could not find what object triggered the segfault, but I do know that is a object, although the segfault happened in different places, most of the time it happened inside a BaseMovingEntity or something like that)

Seth
07-21-2010, 11:28 PM
UnloadMapByName is used in many of the examples, do any of those crash on you? They all seem fine here.

Don't unload a map from within an entity that is on that map. Setup a global callback or something.

speeder
07-21-2010, 11:36 PM
No, the examples don't crash, this is why I posted here, and not on bugs :P I am doing something wrong...

I think that it is somehow related to schedulers... The dialog box that "resets" a level get paused with everything else, thus stop obeying the player... My solution was manually schedule the update while the game is paused...

So, you think it is related to that?

Also, the dialog box calls a global function (that unloads the level), when the function unloads the level, it is "inside" the object? (I mean, the object called a global function... although the scope of unloading is not inside the object, probably the function expect to end and return execution to the object...)

Seth
07-22-2010, 09:18 AM
Also, the dialog box calls a global function (that unloads the level), when the function unloads the level, it is "inside" the object? (I mean, the object called a global function... although the scope of unloading is not inside the object, probably the function expect to end and return execution to the object...)

Yeah, I think that would be a problem. Instead, you should schedule it to happen later if you are inside an entity, like this:


Schedule(100, C_ENTITY_NONE, "UnloadMapAndDoStuff();");
(and have that function in any global file do the real work)

speeder
07-22-2010, 02:56 PM
I did that, and now it crashes MORE...

The thing is that now the stack trace is always the same, so I will post it here to see what you can figure...


#0 0076A2A3 CL_Signal_v1<int>::call(this=0xc525ce4, param1=-1163005939) (e:/local/include/ClanLib/Core/System/../../Signals/signal_v1.h:139)
#1 0076B46C CL_Signal_v1<int>::operator() (this=0xc525ce4, param1=-1163005939) (e:/local/include/ClanLib/Core/System/../../Signals/signal_v1.h:132)
#2 0046CE37 BaseGameEntity::SetDeleteFlag(this=0xc525ce0, bNew=true) (E:/novashellSVN/clanlibstuff/novashell/source/BaseGameEntity.cpp:52)
#3 00000000 0x008f0823 in luabind::detail::returns<void>::call<BaseGameEntity, BaseGameEntity, luabind::detail::null_type, bool>(f={__pfn = &BaseGameEntity::SetDeleteFlag(bool) (../../../SharedLib/luabind/luabind/detail/call.hpp:278)
#4 00000000 0x008be0ef in luabind::detail::call<BaseGameEntity, BaseGameEntity, luabind::detail::null_type, void, bool>(f={__pfn = &BaseGameEntity::SetDeleteFlag(bool) (../../../SharedLib/luabind/luabind/detail/call.hpp:403)
#5 0091202D luabind::detail::mem_fn_callback<void (BaseGameEntity::*)(bool) (../../../SharedLib/luabind/luabind/class.hpp:210)
#6 007D148E boost::detail::function::function_obj_invoker1<luabind::detail::mem_fn_callback<void (BaseGameEntity::*)(bool) (e:/local/include/boost/function/function_template.hpp:132)
#7 0090B23F boost::function1<int, lua_State*>::operator() (this=0x99d7970, a0=0x9cbda70) (e:/local/include/boost/function/function_template.hpp:1012)
#8 0045081D luabind::detail::overload_rep::call(this=0x99d7958 , L=0x9cbda70, force_static_call=false) (E:/novashellSVN/SharedLib/luabind/src/overload_rep.cpp:32)
#9 00449C59 luabind::detail::class_rep::function_dispatcher(L= 0x9cbda70) (E:/novashellSVN/SharedLib/luabind/src/class_rep.cpp:722)
#10 0042BA82 luaD_precall(L=0x9cbda70, func=0xc771f58, nresults=0) (E:/novashellSVN/SharedLib/lua/src/ldo.c:319)
#11 004405A3 luaV_execute(L=0x9cbda70, nexeccalls=4) (E:/novashellSVN/SharedLib/lua/src/lvm.c:589)
#12 0042BCA3 luaD_call(L=0x9cbda70, func=0x9c34290, nResults=0) (E:/novashellSVN/SharedLib/lua/src/ldo.c:377)
#13 004225DC f_call(L=0x9cbda70, ud=0x22f880) (E:/novashellSVN/SharedLib/lua/src/lapi.c:796)
#14 0042B0D9 luaD_rawrunprotected(L=0x9cbda70, f=0x4225b2 <f_call>, ud=0x22f880) (E:/novashellSVN/SharedLib/lua/src/ldo.c:116)
#15 0042BF83 luaD_pcall(L=0x9cbda70, func=0x4225b2 <f_call>, u=0x22f880, old_top=16, ef=0) (E:/novashellSVN/SharedLib/lua/src/ldo.c:461)
#16 00422662 lua_pcall(L=0x9cbda70, nargs=1, nresults=0, errfunc=0) (E:/novashellSVN/SharedLib/lua/src/lapi.c:817)
#17 004508CE luabind::detail::pcall(L=0x9cbda70, nargs=1, nresults=0) (E:/novashellSVN/SharedLib/luabind/src/pcall.cpp:40)
#18 008B9CE5 luabind::detail::proxy_function_void_caller<boost::tuples::tuple<float const*, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >::~proxy_function_void_caller(this=0x22f9d0) (../../../SharedLib/luabind/luabind/detail/call_function.hpp:262)
#19 0052D8A6 MovingEntity::Update(this=0x9cbd140, step=1.00806451) (E:/novashellSVN/clanlibstuff/novashell/source/MovingEntity.cpp:2862)
#20 00512C7E MapManager::Update(this=0x99ce100, step=1.00806451) (E:/novashellSVN/clanlibstuff/novashell/source/MapManager.cpp:468)
#21 004F70B3 GameLogic::Update(this=0x99ce0d8, step=1.00806451) (E:/novashellSVN/clanlibstuff/novashell/source/GameLogic.cpp:999)
#22 0056887E App::Update(this=0xa5e860) (E:/novashellSVN/clanlibstuff/novashell/source/main.cpp:771)
#23 0056B7C1 App::main(this=0xa5e860, argc=1, argv=0x996d370) (E:/novashellSVN/clanlibstuff/novashell/source/main.cpp:1154)
#24 00684F59 WinMain@16() (e:/MingW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/iostream:77)
#25 00747216 main() (e:/MingW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/iostream:77)



As you can see, it is crashing because some entity had a "SetDeleteFlag(true)" inside Update() and caused a crash...

The crash reason, is a sigfault, because "data->in_call = true;" <<< data cannot be read.

On the previous line, data is created as: CL_Signal_v1_Generic *data = impl;

deferencing impl, the result is a seemly valid object, but if I go back some frames in the stack trace, I get a movingentity that when I deference the "this" the result is a unreadable place in the memory (the "this*" itself seemly is valid and can be read, but when I deference it, it cannot be read anymore... Oo)




What I REALLY want, is discover WHAT entity is doing this... I spent hours looking every file in the stack trace, and found no clue on how to figure what .lua file called the offending "SetDeleteFlag" :/

I also tried some brute-forcing (commenting all setdeleteflags that I found and testing) but it is not helping (well, it is showing what IS NOT the fault...)

Seth
07-25-2010, 10:11 AM
Hmm... can you set a breakpoint in BaseGameEntity::SetDeleteFlag right before you do the thing that causes the crash? Seems like it might let you get in and look at the entity vars to see which entity it is.

If you can make a small example that crashes on my version of novashell I'd be glad to take a look and try to debug it.

speeder
07-25-2010, 02:55 PM
I cannot do either, plainly because I can't consistently cause the crash myself (these days the frequency decreased again, it only crashed once in 3 days of work...)