[13:54] <bregma> investigating lp:827958
[14:03] <cnd> bregma, which is that?
[14:05] <bregma> libgrip crash at gdk_x11_window_get_xid() in eog
[14:05] <bregma> looks like a latent bug in eog
[14:06] <bregma> can't be sure 'til I've tracked it down
[14:07] <cnd> yeah
[14:07] <cnd> bregma, seb128 is hounding me about it
[14:07] <cnd> I asked Satoris to take a look
[14:07] <bregma> saw that, that's why I'm looking at it
[14:07] <cnd> cool
[14:09] <Satoris> I think a good step would be to reproduce it on a build that does not have the utouch patch.
[14:10] <bregma> indeed
[14:10] <cnd> it would be great if we could do that :)
[14:10] <bregma> I'm working on that now:  I can reproduce it with the current binary
[14:10]  * cnd is selfish
[14:10] <cnd> oh, that's good
[14:10] <cnd> I didn't know how hard it would be to reproduce
[14:11] <bregma> I do note that there are many warnings emitted because some functions return NULL and there are no logic checks for tat
[14:11] <cnd> bregma, in our code?
[14:11] <bregma> no, in eog
[14:12] <bregma> most functions check their parameters and return erly instead of having logic that handles the error condition where it occurs
[14:12] <bregma> libgrip instead assumes it is handed valid data
[14:14] <bregma> I think this is the cause of the problem, libgrip assumes object invariants hold, eog does not and checks validity of everything all the time
[14:14] <bregma> different design philosophies
[14:15] <cnd> ahh
[15:34] <bregma> there is definitely a logic error in libgrip involving maze of twisty little passages, all different
[16:40] <cnd> bregma, does that mean you can't repro without the libgrip addition?
[16:43] <bregma> correct
[16:43] <cnd> ok
[16:44] <bregma> it looks like a widget and its toplevel get out of synch somehow during a convoluted sequence of signals
[16:44] <bregma> it's a matter of making sure everything is lined up nicely before trying to get actual X11 info
[16:45] <bregma> it is indeed a little maze of twisty passages, all different