[BUG] Cleanup crash in lua call back

[earthsruler]

Hey all,

During the applications execution i do this:

Code: Select all

local window = CEGUI.toFrameWindow( windowManager:createWindow( "AquaLook/FrameWindow", newWindowName ) )
         
window:subscribeEvent( 'DestructStart', DropMenu.HasClosed, DropMenu )


Now if this window is still there when i close the application i get a crash. From what i can see the problem is that during ~System() this is called:

Code: Select all

d_scriptModule->destroyBindings();


followed by:

Code: Select all

WindowManager::getSingleton().destroyAllWindows();
WindowManager::getSingleton().cleanDeadPool();


This in turn fires the DestructStart event to lua resulting in this error.

Code: Select all

[string "DropMenu.lua"]:29: attempt to index global 'CEGUI' (a nil value)


Because all the bindings have been destroyed, when the window is destroyed and DropMenu.HasClosed gets called trying to access the CEGUI namespace fails.

Im not sure what the best solution to this is. Maybe unsubscribing all events before beginning destruction of all windows?

ER.

[CrazyEddie]

Hi,

This is (obviously) a definite bug. I'll add it on mantis shortly.

Im not sure what the best solution to this is. Maybe unsubscribing all events before beginning destruction of all windows?

Do you mean client side, or from within CEGUI? I think for a CEGUI side fix, I might just adjust the order of destruction so that scripting is still up right at the end. From a client code angle, dropping all the event subscriptions would undoubtedly be the way to go - however there is an issue in the lua scripting from 0.5.x and higher whereby the required disconnect functions are not available from lua (we have a tentative fix for this issue). This leaves you with the option of removing the event objects themselves from the event set - it should have the desired effect, though is very "brutal".

CE.

[earthsruler]

Hi,
Do you mean client side, or from within CEGUI?

I was thinking from within CEGUI, the reason being that someone could have new windows being created when one is destroyed and may cause other crash problems. Where as if the callbacks never get called then 'nothing' can go wrong...

ER.

[CrazyEddie]

Ah, right, yes - good point

CE.

[CrazyEddie]

Hi,

Today I committed a fix for this in branches/v0-6 at rev. 1853. In the end I opted for the changed sequence of destruction in System::~System.

While I do acknowledge your point about not firing events due to the possibility of creating windows in response to some other window being destroyed, there are enough other valid reasons - such as resource cleanup - for these events to be fired as normal.

The final solution to this is still not 100% robust; there are still places where it might be possible to trip ourselves up. I think that if there is any chance of a handler being called after bindings have been cleared (not from CEGUI::Window, as that case is sorted), then defensive coding of the scripts should be employed.

BTW, I actually think the window creation at system shutdown is a real, but different, issue. I think some kind of a 'lock' mode on WindowManager should be implemented so that during shutdown we can lock the WindowManager and all attempts at Window creation will fail during this time.

CE.

[earthsruler]

Sweet!! This has fixed my crash but and i did notice that you added the lock stuff into the windowManager. Great idea. much better than simply deregistering callbacks and removes the possibility of creating windows during shutdown.

ER.