On Thu, Jun 13, 2013 at 1:17 AM, Paul K <paulclin...@yahoo.com> wrote:
> Hi John,
>
> I got several reports (from the same machine) of crashes in my
> application when a user types something in wxSTC control. It's
> difficult to reproduce and seems to happen infrequently, but the
> captured stack trace points to wxLuaState::LuaPCall call. This is
> running wxlua 2.8.12.2 and wxwidgets 2.9.5 (compiled at the end of
> April).
>
>
The wxLua C++ event handler callback uses LuaPCall() to run your Lua event
handler function for the wxStyledTextEvent. From the stack it looks like
the event is a char added event.
I'm including the top part of the stack trace below (the full stack is
> in this ticket:
> https://github.com/pkulchenko/ZeroBraneStudio/issues/164), but there
> are several odd things I noticed.
>
> 1. The trace shows lua51!lua_yield call after wxLuaState::LuaPCall
> call, but I don't see any lua_yield calls in that function.
>
>
lua_yield is a coroutine function, are you running coroutines? If so, then
Lua will be swapping lua_States in and out and pausing them whenever it
wants to, making the stack seem very strange.
You're not trying to install event handlers in a coroutine are you? As we
discussed, that's always a bad idea.
> 2. The trace shows wxProgressDialog_delete_function call in the stack,
> but I don't use that component anywhere in the application; the stack
> looks wrong at that point as I wouldn't expect any wxProgressDialog
> call from lua_getinfo.
>
>
Did you ever create a wxProgressDialog? The Lua garbage collector may
simply be running and finally getting around to deleting it.
3. The crash seems to be in this fragment in wxlua/wxlcallb.cpp:
>
> // Don't track the wxEvent since we don't own it and tracking
> it
> // causes clashes in the object registry table since many can
> be
> // created and deleted and the mem address is resused by C++.
> wxlState.wxluaT_PushUserDataType(event, event_wxl_type, false);
> wxlState.LuaPCall(1, 0); // one input no returns
>
> What events are being referred to here as "we don't own it"? Is it
> possible to check for these events explicitly? Any idea why it may be
> crashing here and how to avoid this? Thank you!
>
>
"We" meaning, wxLua/Lua, does not own the allocated memory for the wxEvent
class so even though wxLua pushes it onto the Lua stack wxLua/Lua will not
try to delete it when the function ends. Think of wxMouseEvents, if you
have a very simple event handler function it may happen that each
successive wxMouseEvent will use the same memory. Therefore, wxLua cannot
"track" the event since the Lua garbage collector can be slow to clean up
and we get seemingly duplicate tracked items, but the first one is long
gone, this is merely book keeping.
The event is a wxStyledTextEvent based on the stack.
Can you rebuild in debug mode? The stack should have line numbers which
will clear things up. Everything is "normal" up to LuaPCall, but then I
presume you're running a coroutine that's calling the lua_yield, and wxLua
does use lua_getinfo for a few things so that may be normal, but the
lua_close is very wrong unless you're closing a coroutine, perhaps the
coroutine had a wxProgressDialog and that's why it's getting deleted at
this point? I can't imagine who's calling AddPendingEvent though, are you?
In any case, if you do create a wxProgressDialog I suggest that you
explicitly call dlg:Destroy() on it to ensure that it's cleaned up
immediately instead of waiting for the garbage collector.
Regards,
John
> 0028eb1c 5dac0207 unknown!unknown+0x0
> 0028eb20 02270b3f wx!ZN12wxEvtHandler15AddPendingEventERK7wxEvent+0x1b
> 0028eb40 01ed3fe7 wx!Z38wxLua_wxProgressDialog_delete_functionPPv+0x88a
> 0028eb60 66d85a49 lua51!lua_getinfo+0x1015
> 0028eb70 66d8ddd1 lua51!lua_close+0x1eb9
> 0028ebb0 66d8ea14 lua51!lua_close+0x2afc
> 0028ec50 66d85e34 lua51!lua_getinfo+0x1400
> 0028ed00 66d85f89 lua51!lua_yield+0x81
> 0028ed10 66d86431 lua51!lua_yield+0x529
> 0028ed80 01f65c4e wx!ZN10wxLuaState8LuaPCallEii+0x7c
> 0028edc0 01f5b2da wx!ZN18wxLuaEventCallback7OnEventEP7wxEvent+0x1f4
> 0028ee20 01f5b09b wx!ZN18wxLuaEventCallback11OnAllEventsER7wxEvent+0x59
> 0028ee70 02197e3a
>
> wx!ZNK16wxAppConsoleBase16CallEventHandlerEP12wxEvtHandlerR14wxEventFunctorR7wxEvent+0x42
> 0028eec0 02199839
>
> wx!ZN12wxEvtHandler23ProcessEventIfMatchesIdERK21wxEventTableEntryBasePS_R7wxEvent+0x65
> 0028eef0 02199aa3
> wx!ZN12wxEvtHandler23SearchDynamicEventTableER7wxEvent+0x4f
> 0028ef20 02199ae2 wx!ZN12wxEvtHandler11TryHereOnlyER7wxEvent+0x28
> 0028ef40 02199b48 wx!ZN12wxEvtHandler19ProcessEventLocallyER7wxEvent+0x1a
> 0028ef60 02199bc9 wx!ZN12wxEvtHandler12ProcessEventER7wxEvent+0x63
> 0028ef90 01f72fb0
> wx!ZN16wxStyledTextCtrl12NotifyParentEP14SCNotification+0x252
> 0028f070 01f75022 wx!ZN11ScintillaWX12NotifyParentE14SCNotification+0x1e
> 0028f090 01f82de0 wx!ZN6Editor10NotifyCharEi+0x3a
> 0028f160 01f92f85 wx!ZN6Editor10AddCharUTFEPcjb+0x3e1
> 0028f1c0 01f7c151 wx!ZN13ScintillaBase10AddCharUTFEPcjb+0x9f
> 0028f200 01f766a9 wx!ZN11ScintillaWX9DoAddCharEi+0x6f
> ...
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> wxlua-users mailing list
> wxlua-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
wxlua-users mailing list
wxlua-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxlua-users
