GNOME Bugzilla – Bug 710978
Unittest failures in 3.11
Last modified: 2017-01-15 22:12:38 UTC
There are multiple failures in the test suite due to recent changes in GLib. Most of this stems from bug 710724 making the removal of non-existent sources a critical error. tests/test_source.py:TestSource.test_remove Fails because it is not expecting the critical, we can simply change this test to expect the critical by modifying GLib.log_set_always_fatal and setting it back at the end of the test. tests/test_mainloop.py:TestMainLoop.test_sigint This is a trickier problem because our MainLoop override automatically adds a SIGINT handler and tries to remove it in __del__. I'm pretty sure the problem here is because the "_handler" callback is not returning anything (returns None) which is interpreted as FALSE, telling GLib to remove the handler, we then attempt the remove the handler a second time in __del__. See: https://developer.gnome.org/glib/2.30/glib-The-Main-Event-Loop.html#GSourceFunc https://git.gnome.org/browse/pygobject/tree/gi/overrides/GLib.py?id=3.10.1#n497 tests/test_overrides_gtk.py:TestGtk.test_dialogs Unrelated to the above problems I'm getting a crash when creating a GtkFileChooserDialog with MALLOC_PERTURB_ set: MALLOC_PERTURB_=85 python3 -c "from gi.repository import Gtk; Gtk.FileChooserDialog()" Segmentation fault (core dumped) This looks to be deep in GtkBuilder templates and places sidebar code and needs more debugging...
Created attachment 258254 [details] [review] gtk-demo: Remove spaces from Icon View and Tree View demo folder names This is needed for limiting pyflakes runs to only git in-tree files.
Created attachment 258255 [details] [review] tests: Limit pyflakes to git in-tree Python files This is needed so we don't have to maintain out of tree test scripts and temporary py files as pyflakes compliant.
Created attachment 258256 [details] [review] tests: Fix source testing to handle critical with non-existing sources Silence new critical comming from g_source_remove on non-existing sources. This function still returns False, but we need to silence the new critical so the test suite doesn't fail. See bug 710724.
Created attachment 258257 [details] [review] Add consistent GLib.MainLoop SIGINT cleanup Remove auto cleanup of SIGINT source handling by returning True from the signal callback. This gives the __del__ method consistent cleanup semantics regardless of whether or not a SIGINT occurred.
> MALLOC_PERTURB_=85 python3 -c "from gi.repository import Gtk; Gtk.FileChooserDialog()" > Segmentation fault (core dumped) Oddly this was caused by a change in size to GtkRBNode which for some reason was not being picked up in libgtk_3_la-gtkrbtree.o (that file was not rebuilding). So when stepping between gtktreeview.c and gtkrbtree.c the sizeof(GtkRBNode) was changing from 48 to 56 respectively. This was causing memory corruption. Doing a "make clean; make" fixed this up.
Comment on attachment 258257 [details] [review] Add consistent GLib.MainLoop SIGINT cleanup Attachment 258257 [details] pushed as 57195c9 - Add consistent GLib.MainLoop SIGINT cleanup
Created attachment 258268 [details] [review] tests: Limit pyflakes to git in-tree Python files Update to be more robust
Comment on attachment 258268 [details] [review] tests: Limit pyflakes to git in-tree Python files Hey Simon, thanks for the fixes! What's the use case for "Limit pyflakes to git in-tree Python files"? That's for a developer who wants to create a quick test script? (I usually write them in /tmp) Anyway, this needs to become more robust as we cannot assume that the "git" command is available when running the tests (we still do release tarballs :-) )
(In reply to comment #8) > (From update of attachment 258268 [details] [review]) > Hey Simon, thanks for the fixes! > > What's the use case for "Limit pyflakes to git in-tree Python files"? That's > for a developer who wants to create a quick test script? (I usually write them > in /tmp) I keep a "bugs" folder under pygobject with various bug scripts (usually non-unittestable ui stuff). But I guess this could just go somewhere else. > Anyway, this needs to become more robust as we cannot assume that the "git" > command is available when running the tests (we still do release tarballs :-) ) Makes sense, thanks for looking!