Actually I take back what I said, we can use your fix:
+ g_signal_handlers_disconnect_by_data(G_OBJECT(ih->handle), ih);
+ parent = iupDialogGetNativeParent(ih);
+ if (parent)
+ g_signal_handlers_disconnect_by_func(G_OBJECT(parent),
gtkDialogChildDestroyEvent, ih);
But I think there is another serious problem in what we are doing.
Suppose we have several dialogs that set their parentdialog to the same
main dialog. Those "child" dialogs will all call:
g_signal_connect(G_OBJECT(parent), "destroy",
G_CALLBACK(gtkDialogChildDestroyEvent), ih);
So for the same parent, they will al set destroy, but each time one will
replace another and only the last one set will actually be called. Am I
right? Or I misunderstood g_signal_connect? Does every call to
g_signal_connect with a different data will ensure a different callback
association? I can't remember and I couldn't find this info explicit in
GLIB docs.
Thanks,
Scuri
PS: already committed your contribution.
2017-10-11 11:50 GMT-03:00 Jiří Klimeš <[email protected]>:
> On Tue, 10 Oct 2017 15:21:06 -0300
> Antonio Scuri <[email protected]> wrote:
>
> > Hi,
> >
> > I did not apply this patch because the problem was not there, and
> > it is not a good policy to change the parent dialog from inside the
> > child dialog code.
> >
>
> I don't agree there is no problem there. The issue is that there is a
> race condition (it is not certain when a Gtk signal handler will be
> called), so problems might not always appear. But that doesn't mean
> the problem is not there.
> I have run my test again with the latest code, and the problem is not
> fixed. Please see the attached reports from valgrind. (Actually
> valgrind may help exposing the problem, because it significantly slows
> the program run).
> Anyway, the change I propose fixes the problems and it is a good thing
> to to. It's a proper cleanup of GTK signal handlers, so that they are
> not called on invalid data.
> "destroy" signal handler is connected in gtkDialogMapMethod() and
> *should* be disconnected in gtkDialogUnMapMethod(), because "ih" handler
> passed to the signal handler is not valid any more.
>
> > But there were two problems.
> >
> > First some of the secondary dialogs inside IupPlot were with their
> > parentdialog not set, so this may be causing your crash but I could
> > not reproduce it here. I fixed this anyway.
> >
> > Second, the iuptest application shows the IupPlot inside an
> > IupTabs, and there was an error in IupTabs in GTK. It is now fixed
> > and that application is not crashing anymore. Don't know it is the
> > same case of your application.
> >
>
> As for your changes, they might be right and prevent some (other)
> problems. However, I am not able to assess that. But they have not
> solved the issue I have described.
>
> > Thanks for reporting anyway. Hope that these fixes solves your
> > problem too.
> >
> > Best,
> > Scuri
> >
> Best regards,
> blueowl
>
>
> >
> > 2017-10-03 12:55 GMT-03:00 <[email protected]>:
> >
> > > Hello Antonio (and list),
> > >
> > > while testing a plot functionality I encountered a crash when
> > > destroying a dialog.
> > > It is a Gtk-related issue and happens due to a Gtk signal handler
> > > being called on
> > > an invalid data.
> > >
> > > I have prepared and tested a fix for the problem. The patch is
> > > attached to this
> > > message and also published on github:
> > > https://github.com/blueowl04/iup-github/commits/gtk-crash-fix
> > >
> > > The commit message describes a test case and also contains a call
> > > stack grabbed by valgrind.
> > >
> > > Best regards,
> > > blueowl
> > >
> > > ------------------------------------------------------------
> > > ------------------
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > _______________________________________________
> > > Iup-users mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/iup-users
> > >
> > >
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Iup-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/iup-users
