[solved] Hud menu causes crash

[The Jo]

How to reproduce the bug in the trunk:
1. load the level "Pirate Attack".
2. Press F3. (directly at the beginning)

=======================================================
= time: Thu Aug 11 22:57:11 2011
=======================================================
Program received signal SIGSEGV, Segmentation fault.
0x0630956a in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /usr/lib/i386-linux-gnu/libstdc++.so.6
(gdb)
#0 0x0630956a in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#1 0x03edd3a2 in orxonox::QuestManager::getId (this=0x9df9cb8, item=0xb604c68) at /home/jo/orxonox/trunk/src/modules/questsystem/QuestManager.cc:402
#2 0x03f06d61 in tolua_Questsystem_orxonox_QuestManager_getId00 (tolua_S=0x9f7ce20) at /home/jo/orxonox/trunk/build/src/modules/questsystem/./ToluaBindQuestsystem.cc:401
#3 0x03f06f2b in tolua_Questsystem_orxonox_QuestManager_getId01 (tolua_S=0x9f7ce20) at /home/jo/orxonox/trunk/build/src/modules/questsystem/./ToluaBindQuestsystem.cc:439
#4 0x002162ea in ?? () from /usr/lib/liblua5.1.so.0
#5 0x0022145a in ?? () from /usr/lib/liblua5.1.so.0
#6 0x002167d0 in ?? () from /usr/lib/liblua5.1.so.0
#7 0x00211771 in ?? () from /usr/lib/liblua5.1.so.0
#8 0x00215df3 in ?? () from /usr/lib/liblua5.1.so.0
#9 0x00215e55 in ?? () from /usr/lib/liblua5.1.so.0
#10 0x00211598 in lua_pcall () from /usr/lib/liblua5.1.so.0
#11 0x0111473b in orxonox::LuaState::doString (this=0x9f7cd30, code=..., sourceFileInfo=...) at /home/jo/orxonox/trunk/src/libraries/core/LuaState.cc:188
#12 0x01162e1f in orxonox::GUIManager::executeCode (this=0x9e8ba78, str=...) at /home/jo/orxonox/trunk/src/libraries/core/GUIManager.cc:420
#13 0x0116320e in orxonox::GUIManager::showGUIExtra (this=0x9e8ba78, name=..., ptr=..., bHidePrevious=false, bNoInput=false) at /home/jo/orxonox/trunk/src/libraries/core/GUIManager.cc:455
#14 0x08285864 in orxonox::GUIOverlay::changedVisibility (this=0xb1dc790) at /home/jo/orxonox/trunk/src/modules/overlays/GUIOverlay.cc:76
#15 0x006cd622 in orxonox::BaseObject::setVisible (this=0xb1dc790, bVisible=true) at /home/jo/orxonox/trunk/src/libraries/core/BaseObject.h:104
#16 0x006cdb7d in orxonox::OrxonoxOverlay::show (this=0xb1dc790) at /home/jo/orxonox/trunk/src/orxonox/overlays/OrxonoxOverlay.h:97
#17 0x00838bbc in orxonox::OrxonoxOverlay::showOverlay (name=...) at /home/jo/orxonox/trunk/src/orxonox/overlays/OrxonoxOverlay.cc:390
#18 0x0070a004 in orxonox::detail::FunctorCaller<void, void, false, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, void, void, void, void>::call (functionPointer=0x838af2 <orxonox::OrxonoxOverlay::showOverlay(std::string const&)>, param1=...) at /home/jo/orxonox/trunk/src/libraries/core/command/Functor.h:434
#19 0x00709f72 in orxonox::FunctorTemplate<void, void, false, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, void, void, void, void>::operator() (this=0x9c3ec10, object=0x0, param1=..., param2=..., param3=..., param4=..., param5=...) at /home/jo/orxonox/trunk/src/libraries/core/command/Functor.h:501
#20 0x00689a1b in orxonox::FunctorMember<void>::operator() (this=0x9c3ec10, param1=..., param2=..., param3=..., param4=..., param5=...) at /home/jo/orxonox/trunk/src/libraries/core/command/Functor.h:332
#21 0x0119cea6 in orxonox::Executor::operator() (this=0x9c3eb98, arg1=...) at /home/jo/orxonox/trunk/src/libraries/core/command/Executor.h:109
#22 0x0119ac63 in orxonox::CommandEvaluation::query (this=0xa07d790, error=0xbfab5c6c) at /home/jo/orxonox/trunk/src/libraries/core/command/CommandEvaluation.cc:159
#23 0x0119a969 in orxonox::CommandEvaluation::execute (this=0xa07d790) at /home/jo/orxonox/trunk/src/libraries/core/command/CommandEvaluation.cc:114
#24 0x006cdaf6 in orxonox::SimpleCommand::execute (this=0xa07d788, abs=1, rel=1) at /home/jo/orxonox/trunk/src/libraries/core/input/InputCommands.h:90
#25 0x011e8823 in orxonox::Button::execute (this=0xa38b8e8, mode=orxonox::KeybindMode::OnPress, abs=1, rel=1) at /home/jo/orxonox/trunk/src/libraries/core/input/Button.h:83
#26 0x011e8a28 in orxonox::KeyBinder::buttonPressed (this=0xa38ac70, evt=...) at /home/jo/orxonox/trunk/src/libraries/core/input/KeyBinder.h:197
#27 0x011f9b39 in orxonox::InputHandler::buttonEvent<orxonox::KeyEvent&> (this=0xa38ac70, device=0, button=...) at /home/jo/orxonox/trunk/src/libraries/core/input/InputHandler.h:124
#28 0x011fb049 in boost::_mfi::mf3<void, orxonox::InputHandler, unsigned int, orxonox::KeyEvent&, orxonox::ButtonEvent::EnumToType<(orxonox::ButtonEvent::Value)0> >::operator() (this=0xc0e9a80, p=0xa38ac70, a1=0, a2=..., a3=...) at /usr/include/boost/bind/mem_fn_template.hpp:393
#29 0x011fad02 in boost::_bi::list4<boost::_bi::value<orxonox::InputHandler*>, boost::_bi::value<unsigned int>, boost::_bi::value<orxonox::KeyEvent>, boost::_bi::value<orxonox::ButtonEvent::EnumToType<(orxonox::ButtonEvent::Value)0> > >::operator()<boost::_mfi::mf3<void, orxonox::InputHandler, unsigned int, orxonox::KeyEvent&, orxonox::ButtonEvent::EnumToType<(orxonox::ButtonEvent::Value)0> >, boost::_bi::list0> (this=0xc0e9a88, f=..., a=...) at /usr/include/boost/bind/bind.hpp:457
#30 0x011fa97a in boost::_bi::bind_t<void, boost::_mfi::mf3<void, orxonox::InputHandler, unsigned int, orxonox::KeyEvent&, orxonox::ButtonEvent::EnumToType<(orxonox::ButtonEvent::Value)0> >, boost::_bi::list4<boost::_bi::value<orxonox::InputHandler*>, boost::_bi::value<unsigned int>, boost::_bi::value<orxonox::KeyEvent>, boost::_bi::value<orxonox::ButtonEvent::EnumToType<(orxonox::ButtonEvent::Value)0> > > >::operator() (this=0xc0e9a80) at /usr/include/boost/bind/bind_template.hpp:20
#31 0x011fa6ad in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf3<void, orxonox::InputHandler, unsigned int, orxonox::KeyEvent&, orxonox::ButtonEvent::EnumToType<(orxonox::ButtonEvent::Value)0> >, boost::_bi::list4<boost::_bi::value<orxonox::InputHandler*>, boost::_bi::value<unsigned int>, boost::_bi::value<orxonox::KeyEvent>, boost::_bi::value<orxonox::ButtonEvent::EnumToType<(orxonox::ButtonEvent::Value)0> > > >, void>::invoke (function_obj_ptr=...) at /usr/include/boost/function/function_template.hpp:153
#32 0x011cac5f in boost::function0<void>::operator() (this=0x9fae020) at /usr/include/boost/function/function_template.hpp:1013
#33 0x011c6bd7 in orxonox::InputManager::preUpdate (this=0x9fa4ed0, time=...) at /home/jo/orxonox/trunk/src/libraries/core/input/InputManager.cc:403
#34 0x01151c89 in orxonox::Core::preUpdate (this=0x9c59910, time=...) at /home/jo/orxonox/trunk/src/libraries/core/Core.cc:445
#35 0x010ef159 in orxonox::Game::run (this=0x9c59748) at /home/jo/orxonox/trunk/src/libraries/core/Game.cc:188
#36 0x0066563f in orxonox::main (strCmdLine=...) at /home/jo/orxonox/trunk/src/orxonox/Main.cc:100
#37 0x08049718 in main (argc=1, argv=0xbfab6164) at /home/jo/orxonox/trunk/src/Orxonox.cc:78
(gdb)

[Mozork]

I can't reproduce it. But it seems to me, that somehow the string returned by QuestManager::getId doesn't exist, I wonder why. Can anyone else reproduce it?

[x3n]

I rather assume the "Quest* item" pointer in getId() is invalid. item->getId() then returns an invalid const-ref to a string (const std::string&), which can be seen like an invalid pointer. QuestManager tries to create a copy of this string (since the function returns std::string, no reference) which fails, because the original is invalid.

But no clue why the Quest pointer could be invalid. I can't reproduce it. Maybe this is a general lua <-> orxonox problem at Jo's computer? Then we should find other cases where this leads to a crash. But where else do we use orxonox pointers in lua?

Edit: damian, I see you added some asserts. But according to the crashlog, item is not NULL (#1 0x03edd3a2 in orxonox::QuestManager::getId (this=0x9df9cb8, item=0xb604c68)). So you rather use assert(dynamic_cast<Quest*>(item)) or something along these lines.

[Mozork]

I noticed, that the pointer is not NULL, after adding the asserts, that is why I didn't mention it here. Perhaps the problem occurs because the QuestManager has two methods called getId() one with a Quest as argument and one with a QuestHint. I have renamed them, @jo could you please test again.

[x3n]

http://www.codenix.com/~tolua/tolua++.html#functions

Tolua supports overloaded functions and I guess the pointer types are distinct even in lua. Also I don't see any code in lua where hints and quests could be confused. But it's surely worth a try.

[The Jo]

Damian, I tested your version. The bug is still there. But I realised, that the discription how to trigger the bug is not correct. That's why nobody was able neither to reproduce nor to fix the bug so far.
1. open a quest-level (pirate attack or fight in our back)
2. close it again.
3. restart the level via the "quickstart" button or via the game menu.
4. Press F3. -> crash.

[x3n]

Ah great, now I can reproduce it as well.
And like that it also makes much more sense: The lua script keeps a list of all quests. It almost certainly doesn't erase this list if the level ends, hence it contains dangling pointers, which leads to the crash.


Edit:
There are plenty of ways to solve this, but I think this shows a fundamental problem of elements that exist only in lua: We can't control them. We could add a callback which calls a cleanup function in all gui scripts when the level ends, but we still have to pay much attention to implement this everywhere where necessary and also to clean up everything.

Wouldn't it be much easier if the quest gui is linked to a C++ object that exists only during one level? I remember we discussed that already a few times in the past and I know that this will probably introduce other problems. But right now we have like two different worlds, the C++ world where each BaseObject is destroyed at the end of a level, and the Lua world where stuff exists across different levels and even gamestates.

[Mozork]

In this case, the bug can actually be resolved in a much simpler way, the only problem was, that I wanted the QuestGUI to always open in the last state, everything else is generated anew each time the qui is opened. So the solution was to remove this feature, now the QuestGUI always opens with the first quest open, another solution would be to move that variable to the QuestManager as a WeakPointer.

[x3n]

Jup I assumed that there is an easy way. I was talking about the general problem that we have no encapsulation or scope in lua. Even if you make your script work by adding stuff to QuestManager, the quest gui might still exist when QuestManager doesn't exist anymore.

There are more problems loosely related to this, e.g. if there's a syntax error anywhere in a gui script, the main menu will not show up after startup. Even non-syntactical errors lead to the same problem if they are in onLoad().

Also remember that we have quite a twisted logic to ensure that you cannot open a menu while another menu is open. However this logic exists only in lua and if you use the default keybindings. Just alt+tab to the console and use the "toggleGUI" command. Try to open DockingDialog in the main menu and you get a crash. And also good look closing the MainMenu (without console ) if you managed to open it in game. Open the chat box with toggleGUI and you are not able to type text.

You may argue that I'm abusing the console (and you would be right), but it shows that it's really easy to produce inconsistent gui states. I have a bad feeling about running Lua decoupled in parallel to orxonox. After all it's possible (and also very much intended) to use pointers to C++ objects in Lua, so we need some kind of control. However I'm not the Lua expert here, so I can't come up with a solution right now. However I would generally try to encapsule a lua script / gui within the scope of a C++ object.

[Mozork]

Yes, you are absolutely right about that.

I guess, as you said, one solution would be to basically move the logic behind the GUI sheets (i.e. GUISheet.lua and SheetManager.lua) into C++.