[BUG] Cleanup crash in lua call back

If you found a bug in our library or on our website, please report it in this section. In this forum you can also make concrete suggestions or feature requests.

Moderators: CEGUI MVP, CEGUI Team

earthsruler
Quite a regular
Quite a regular
Posts: 74
Joined: Mon Apr 28, 2008 23:21
Location: Australia

[BUG] Cleanup crash in lua call back

Postby earthsruler » Mon Nov 10, 2008 01:17

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.

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Re: [BUG] Cleanup crash in lua call back

Postby CrazyEddie » Mon Nov 10, 2008 10:04

Hi,

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

earthsruler wrote: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
Quite a regular
Quite a regular
Posts: 74
Joined: Mon Apr 28, 2008 23:21
Location: Australia

Re: [BUG] Cleanup crash in lua call back

Postby earthsruler » Mon Nov 10, 2008 23:49

CrazyEddie wrote: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.

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Postby CrazyEddie » Tue Nov 11, 2008 09:54

Ah, right, yes - good point :)

CE.

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

Postby CrazyEddie » Sun Nov 16, 2008 15:12

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
Quite a regular
Quite a regular
Posts: 74
Joined: Mon Apr 28, 2008 23:21
Location: Australia

Postby earthsruler » Mon Nov 17, 2008 05:18

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.


Return to “Bug Reports, Suggestions, Feature Requests”

Who is online

Users browsing this forum: No registered users and 18 guests