Re: [Iup-users] SIGSEGV when resuming coroutine from iup callback
Quoting Andrew Robinson (2022-05-27 21:34:38) > Actually there isn't any nightly or experimental builds, I was just giving > Antonio a hint :) > All the bugs I've found can wait but for major bugs, the few people > that require an emergency build can continue on with their project and > confirm the fix for IUP at the same time. Right, makes sense. I have a workaround in place for this particular bug, so I'm good for now, fwiw. Thanks gain -- :wq ^X^Cy^K^X^C^C^C^C ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] SIGSEGV when resuming coroutine from iup callback
Actually there isn't any nightly or experimental builds, I was just giving Antonio a hint to follow because sometimes there are issues that people can't wait for the next release in order for it to be fixed. A major planned released should never be prematurely released until it's ready, so in between releases there should at least be "emergency" releases (i.e. -- use at your own risk) on an as-needed basis. Most open source projects have nightly builds available so whatever plan works for everyone involved should be executed. All the bugs I've found can wait but for major bugs, the few people that require an emergency build can continue on with their project and confirm the fix for IUP at the same time. On 5/27/2022 at 9:07 AM, Ico wrote: >Quoting Andrew Robinson (2022-05-27 17:15:20) >> Hopefully that will be in the nightly/experimental builds of IUP and not a >> major release. I don't want a new version of IUP released until all current >> issues are resolved and any new features are mature enough for a release. > >Fair enough; I was not aware there was are nightly builds available, where >can I find these? > >Thank you, > >Ico ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] SIGSEGV when resuming coroutine from iup callback
Quoting Andrew Robinson (2022-05-27 17:15:20) > Hopefully that will be in the nightly/experimental builds of IUP and not a > major release. I don't want a new version of IUP released until all current > issues are resolved and any new features are mature enough for a release. Fair enough; I was not aware there was are nightly builds available, where can I find these? Thank you, Ico ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] SIGSEGV when resuming coroutine from iup callback
Hopefully that will be in the nightly/experimental builds of IUP and not a major release. I don't want a new version of IUP released until all current issues are resolved and any new features are mature enough for a release. On 5/27/2022 at 5:02 AM, Antonio Scuri wrote: Hi, > Would it be possible to release a new iup version from the latest svn > master to have this fix available in the official build? That depends on the changes. Can you send me a diff? Em qui., 26 de mai. de 2022 às 16:08, Ico escreveu: Hi Scuri, I spent the afternoon digging myself through the code, learning the internals of coroutines in the Lua interpreter and about how iuplua handles the lua_State context; my conclusion is that iuplua seems to pass around the wrong lua_State, using the thread `L` instead of the main `L`, which causes a nasty mixup when resuming coroutines from a iup callback. I came up with a fix that makes sure the main lua_State is stored and used in the iup callbacks, which seems to solve my problem. As I prepared my patch to play nicely with the lastest iup version I cloned the svn repo - only to find that exactly this change was already part of the upstream code, commit r5923 with the log message "Using the main thread for the IupLua callbacks" So, the bad news is that I wasted a few hours, the good news is that I learned a lot and got my problem fixed. Would it be possible to release a new iup version from the latest svn master to have this fix available in the official build? Thanks! Ico Quoting Ico (2022-05-26 14:00:01) > I'm still running into some issues when mixing iup and coroutines, the > snippet below results in a reproducable crash on both linux and win32. -- :wq ^X^Cy^K^X^C^C^C^C ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] SIGSEGV when resuming coroutine from iup callback
Quoting Antonio Scuri (2022-05-27 14:02:18)
> > Would it be possible to release a new iup version from the latest svn
> > master to have this fix available in the official build?
>
> That depends on the changes. Can you send me a diff?
I mean commit r5923 which is already part of the iup subversion repo, but has
not end up in a release yet:
Thanks,
$ svn log -c5923
r5923 | scuri | 2021-01-06 21:37:25 +0100 (Wed, 06 Jan 2021) | 1 line
Using the main thread for the IupLua callbacks
$ svn diff -c5923
Index: trunk/iup/srclua5/iuplua.c
===
--- trunk/iup/srclua5/iuplua.c (revision 5922)
+++ trunk/iup/srclua5/iuplua.c (revision 5923)
@@ -644,9 +644,32 @@
/*/
/* used by callbacks */
+#if LUA_VERSION_NUM == 501
+static void luaL_checkversion(lua_State *L)
+{
+ if (lua_pushthread(L) == 0)
+luaL_error(L, "Must call iup.Open in main thread");
+
+ lua_setfield(L, LUA_REGISTRYINDEX, "MAINTHREAD");
+}
+#endif
+
+static lua_State* get_main_thread(lua_State* L)
+{
+ lua_State* main_L;
+#if LUA_VERSION_NUM == 501
+ lua_getfield(L, LUA_REGISTRYINDEX, "MAINTHREAD");
+#else
+ lua_rawgeti(L, LUA_REGISTRYINDEX, LUA_RIDX_MAINTHREAD);
+#endif
+ main_L = lua_tothread(L, -1);
+ lua_pop(L, 1);
+ return main_L;
+}
+
IUPLUA_SDK_API void iuplua_plugstate(lua_State *L, Ihandle *ih)
{
- IupSetAttribute(ih, "_IUPLUA_STATE_CONTEXT",(char *) L);
+ IupSetAttribute(ih, "_IUPLUA_STATE_CONTEXT",(char *)get_main_thread(L));
if (IupGetGlobal("IUPLUA_THREADED"))
{
@@ -1388,6 +1411,8 @@
{ NULL, NULL },
};
+ luaL_checkversion(L);
+
if (!il_open(L))
return 0;
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] SIGSEGV when resuming coroutine from iup callback
Hi, > Would it be possible to release a new iup version from the latest svn > master to have this fix available in the official build? That depends on the changes. Can you send me a diff? Em qui., 26 de mai. de 2022 às 16:08, Ico escreveu: > Hi Scuri, > > I spent the afternoon digging myself through the code, learning the > internals of coroutines in the Lua interpreter and about how iuplua > handles the lua_State context; my conclusion is that iuplua seems to > pass around the wrong lua_State, using the thread `L` instead of the > main `L`, which causes a nasty mixup when resuming coroutines from > a iup callback. > > I came up with a fix that makes sure the main lua_State is stored > and used in the iup callbacks, which seems to solve my problem. > > As I prepared my patch to play nicely with the lastest iup version > I cloned the svn repo - only to find that exactly this change was > already part of the upstream code, commit r5923 with the log message > "Using the main thread for the IupLua callbacks" > > So, the bad news is that I wasted a few hours, the good news is that I > learned a lot and got my problem fixed. > > Would it be possible to release a new iup version from the latest svn > master to have this fix available in the official build? > > Thanks! > > Ico > > > Quoting Ico (2022-05-26 14:00:01) > > > I'm still running into some issues when mixing iup and coroutines, the > > snippet below results in a reproducable crash on both linux and win32. > > -- > :wq > ^X^Cy^K^X^C^C^C^C > > > ___ > Iup-users mailing list > Iup-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/iup-users > ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] SIGSEGV when resuming coroutine from iup callback
Hi Scuri, I spent the afternoon digging myself through the code, learning the internals of coroutines in the Lua interpreter and about how iuplua handles the lua_State context; my conclusion is that iuplua seems to pass around the wrong lua_State, using the thread `L` instead of the main `L`, which causes a nasty mixup when resuming coroutines from a iup callback. I came up with a fix that makes sure the main lua_State is stored and used in the iup callbacks, which seems to solve my problem. As I prepared my patch to play nicely with the lastest iup version I cloned the svn repo - only to find that exactly this change was already part of the upstream code, commit r5923 with the log message "Using the main thread for the IupLua callbacks" So, the bad news is that I wasted a few hours, the good news is that I learned a lot and got my problem fixed. Would it be possible to release a new iup version from the latest svn master to have this fix available in the official build? Thanks! Ico Quoting Ico (2022-05-26 14:00:01) > I'm still running into some issues when mixing iup and coroutines, the > snippet below results in a reproducable crash on both linux and win32. -- :wq ^X^Cy^K^X^C^C^C^C ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] SIGSEGV when resuming coroutine from iup callback
I'm still running into some issues when mixing iup and coroutines, the
snippet below results in a reproducable crash on both linux and win32.
require "iuplua"
iup.SetGlobal("IUPLUA_THREADED", 1)
local function main()
local co = coroutine.running()
local dlg = iup.dialog {
iup.button {
title = "&Button",
-- on button press, resume the coroutine
action = function()
coroutine.resume(co)
end
}
}
-- show the dialog and yield until we get resumed
dlg:show()
coroutine.yield()
end
local co = coroutine.create(main)
coroutine.resume(co)
iup.MainLoop()
This is a minimized fragment from my actual code base: the UI mainly runs in
coroutine context; a widget is created and the coroutine yield()s, until an
action is triggered from a iup callback which tries to resume() the coroutine.
This seems not to be related to the garbage collection issues I ran in before,
which needed me to set the "IUPLUA_THREADED" global to prevent lua from GCing
coroutines;
gdb stack trace:
Thread 1 "lua" received signal SIGSEGV, Segmentation fault.
#0 0x55a213c8 in ()
#1 0x55561e62 in resume (L=L@entry=0x55a41998,
ud=ud@entry=0x7fffc85c) at ldo.c:777
#2 0x55560f7a in luaD_rawrunprotected
(L=L@entry=0x55a41998, f=f@entry=0x55561de0 ,
ud=ud@entry=0x7fffc85c) at ldo.c:145
#3 0x55562118 in lua_resume (L=L@entry=0x55a41998,
from=from@entry=0x55a41998, nargs=,
nargs@entry=0, nresults=nresults@entry=0x7fffc89c) at ldo.c:825
#4 0x5557b891 in auxresume (L=L@entry=0x55a41998,
co=co@entry=0x55a41998, narg=0) at lcorolib.c:39
#5 0x5557bbff in luaB_coresume (L=0x55a41998) at lcorolib.c:59
#6 0x55561c01 in precallC (f=0x5557bbd0 ,
nresults=0, func=0x55a63b90, L=0x55a41998) at ldo.c:507
#7 luaD_precall (L=L@entry=0x55a41998, func=,
func@entry=0x55a63b90, nresults=0) at ldo.c:573
#8 0x5556ffec in luaV_execute (L=L@entry=0x55a41998,
ci=) at lvm.c:1636
#9 0x55561fd0 in ccall (inc=65537, nResults=,
func=, L=0x55a41998) at ldo.c:610
#10 luaD_callnoyield (L=0x55a41998, func=,
nResults=) at ldo.c:628
#11 0x55560f7a in luaD_rawrunprotected
(L=L@entry=0x55a41998, f=f@entry=0xc930 ,
ud=ud@entry=0x7fffcb60) at ldo.c:145
#12 0x55562360 in luaD_pcall
(L=L@entry=0x55a41998, func=func@entry=0xc930 ,
u=u@entry=0x7fffcb60, old_top=96, ef=)
at ldo.c:931
#13 0xec6c in lua_pcallk
(L=0x55a41998, nargs=, nresults=1, errfunc=, ctx=, k=)
at lapi.c:1067
#14 0x77c4ffba in docall () at ./iuplua.so
#15 0x77c50298 in iuplua_call () at ./iuplua.so
#16 0x77b7f6b1 in gtkButtonClicked () at
/home/ico/sandbox/rodney/vestel/linux/iup/libiup.so
#17 0x76f7c949 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x76f95499 in g_signal_emit_valist () at
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#19 0x76f956bf in g_signal_emit () at
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#20 0x773d0351 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#21 0x776841a4 in () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#22 0x76f7c877 in () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
