GNOME Bugzilla – Bug 378662
introduction of pango-1.14.8 makes 'make test' of Gtk2-1.141 to fail; with pango-1.14.7 - OK
Last modified: 2008-08-17 18:35:52 UTC
Steps to reproduce: 1. I'll upload the script if necessary 2. 3. Stack trace: Other information: I have rebuilt all what depends on 'pango' and found out that with introduction of pango-1.14.8 'make test' of Gtk2-1.141 fails; with pango-1.14.7 it's OK; all other libraries are the same. Please wait until I upload the files.
Created attachment 77080 [details] screen output of the failing 'make test'
Created attachment 77081 [details] screen output of 'make test' which is OK
Created attachment 77082 [details] Makefile of failing 'make test' of Gtk2-1.141
Created attachment 77083 [details] Makefile of Gtk2-1.141 for which 'make test' is OK
I don't see anything Pango related to the failure.
(In reply to comment #5) > I don't see anything Pango related to the failure. > Look, I checked this probably three times - just this one change (pango-1.14.7 -> pango-1.14.8) makes the thing to fail. I have no idea what is; maybe, it's use of some private API which changed, or a race condition. That's why I filed the bug against Gtk, though, of course, I'm not sure it's Gtk (Perl module) problem - there are many things on the way. Let's hope Thorstem, muppet and others from Perl bindings will help us.
So, maybe you can look at the test to see what it's doing?
(In reply to comment #7) > So, maybe you can look at the test to see what it's doing? > Symmetrically, should I suggest you to look into the code of my AppsFromScratch while I'm still alive and well in case of problems with my code ? I think it's best when developers themselves look into their code - ultimately we all benefit. For example, if I start looking into the failing test, I won't be able to spend the time on developing and debugging my code. I think each of us is more efficient with his/her own code than with somebody else's, so we all will be more productive dealing as much as possible with our own code.
(In reply to comment #8) > (In reply to comment #7) > > So, maybe you can look at the test to see what it's doing? > > > > Symmetrically, should I suggest you to look into the code of my > AppsFromScratch while I'm still alive and well in case of problems > with my code ? > > I think it's best when developers themselves look into their code > - ultimately we all benefit. > > For example, if I start looking into the failing test, I won't be able > to spend the time on developing and debugging my code. > > I think each of us is more efficient with his/her own code than with > somebody else's, so we all will be more productive dealing as much as > possible with our own code. Right, but it's not Pango at all. I did take a second look at my ChangeLog between 1.14.7 and 1.14.8 and found no reason whatsoever to break a test. I would have been more than happy to look at the code if it was in gtk+. But with the Perl bindings, that's not as easy as you think. I don't know Perl, never looked at our Perl bindings, and have no idea about AppsFromScratch... You are observing the failure, and you can pinpoint it to a single line that is causing the change fairly easily, and copy it in the bug. FWIW, the Makefiles you attached are not really helpful. It may be if you attach the test case that is failing, or give a URL to it.
(In reply to comment #1) > Created an attachment (id=77080) [edit] > screen output of the failing 'make test' The relevant bits in there are: > t/GtkItemFactory...................Gtk-WARNING **: Unable to locate theme engine in module_path: "galaxy", at t/GtkItemFactory.t line 90. > > # Failed test (t/GtkItemFactory.t at line 111) > # The object isn't defined > > # Failed test (t/GtkItemFactory.t at line 112) > # The object isn't defined > # Looks like you failed 2 tests of 58. > dubious > Test returned status 2 (wstat 512, 0x200) > DIED. FAILED tests 3-4 > Failed 2/58 tests, 96.55% okay (less 41 skipped tests: 15 okay, 25.86%) Lines 111 and 112 of GtkItemFactory.t are > isa_ok( $fac->get_widget_by_action(2), "Gtk2::Widget" ); > isa_ok( $fac->get_item_by_action(2), "Gtk2::MenuItem" ); The error "The object isn't defined" means that the get_foo_by_action() calls are returning undef (which is perl for NULL). The C sources for gtk_item_factory_get_widget_by_action() and gtk_item_factory_get_item_by_action() don't give much to go on. get_item_by_action() is a wrapper for get_widget_by_action(), and get_widget_by_action() just looks up and returns an existing object. My only guess as to why a change in pango would cause this to break is that the associated widget is not being created correctly. However, the test log is littered with messages about a missing theme and parse errors in your ~/.fonts.conf. Please fix those and rerun so that we can rule out undefined behavior there. (The fonts.conf one is the most suspicious; perhaps the font needed by the menu item is missing?) Between a hard disk failure which wiped my sandboxes, a late project at $DAYJOB, and the Thanksgiving holiday, i can't really investigate any further than this in any reasonable timeframe.
I had a little bit closer look at pango and here is what I found: 1) " 31] 6:38 sergei@comp.home.net:/maxtor5/sergei/AppsFromScratchWD> grep warning build/pango-1.14.8/make.log | wc -l 27 [32] 6:38 sergei@comp.home.net:/maxtor5/sergei/AppsFromScratchWD> grep warning build/pango-1.14.7/make.log | wc -l 25 [33] 6:38 sergei@comp.home.net:/maxtor5/sergei/AppsFromScratchWD> " - i.e. pango-1.14.8 has more warnings than 1.14.7; 2) " [34] 6:39 sergei@comp.home.net:/maxtor5/sergei/AppsFromScratchWD> grep warning build/pango-1.14.7/make.log | sort > pango-1.14.7.warnings [35] 6:39 sergei@comp.home.net:/maxtor5/sergei/AppsFromScratchWD> grep warning build/pango-1.14.8/make.log | sort > pango-1.14.8.warnings [36] 6:39 sergei@comp.home.net:/maxtor5/sergei/AppsFromScratchWD> diff pango-1.14.8.warnings pango-1.14.7.warnings 7,8d6 < pangocairo-render.c:421: warning: return type defaults to 'int' < pangocairo-render.c:433: warning: control reaches end of non-void function " To me the last one, i.e. " pangocairo-render.c:433: warning: control reaches end of non-void function " looks like a bug - this means the function was supposed to return something, but there is no 'return <expression>;' statement at the end.
> < pangocairo-render.c:421: warning: return type defaults to 'int' > < pangocairo-render.c:433: warning: control reaches end of non-void function Checked it. Nothing serious. A "void" return type from a new static function was ommitted by mistake, and defaulting to int, it was lacking a return. Adding back the void fixed both. So, no undefined behavior, no.
(In reply to comment #0) > Steps to reproduce: > 1. I'll upload the script if necessary That would be indeed a good start -- instead of bickering about who should look at whose code. I downloaded AppsFromScratch.20060710.20060817.tar.gz (don't know which YYMMDD means what, but it seems the latest), unpacked, ran ./bin/build.pl, watched it doing strange things like adding random directories with Gwyddion modules from my home to LD_LIBRARY_PATH, and finally hanging on Cairo-0.92 installation with This module requires ExtUtils::Depends to install itself. Install ExtUtils::Depends from CPAN? [y] in the log. I gave up. So I installed the perl stuff via my distro means, except for Gtk2-1.141 that I downloaded from CPAN. For 1. My distro's pango-1.14.6 package 2. Package I built from pango-1.14.7 source 3. Package I built from pango-1.14.8 source I did in Gtk2-1.141 source directory: make clean perl Makefile.PL make make test The test is IMO a bit strange because it depends on X server running (therefore the reproducibility for different people is probably poor), but anyway, I got identical outputs (except the timing) in all three cases, a few Gdk-CRITICALs and the following summary: All tests successful (54 subtests UNEXPECTEDLY SUCCEEDED), 2 tests and 57 subtests skipped. Files=198, Tests=3982, 27 wallclock secs (18.09 cusr + 4.52 csys = 22.61 CPU) So: how does someone else reproduce the problem?
(In reply to comment #13) > The test is IMO a bit strange because it depends on X server running (therefore > the reproducibility for different people is probably poor), It is strange, yes, but that's the nature of testing a gui toolkit. If there is no value in DISPLAY, the test suite skips everything that requires an X connection. This mode is used for building RPMs, for example. The reproducibility is decent there. The 54 "unexpectedly succeeded" tests are marked "TODO" to get around differences in window managers. Some of the things we bind can't really be tested without actually trying them out...
(In reply to comment #13) > (In reply to comment #0) > > Steps to reproduce: > > 1. I'll upload the script if necessary > > That would be indeed a good start -- instead of bickering about who should look > at whose code. > > I downloaded AppsFromScratch.20060710.20060817.tar.gz (don't know which YYMMDD > means what, but it seems the latest), unpacked, ran ./bin/build.pl, watched it > doing strange things like adding random directories with Gwyddion modules from > my home to LD_LIBRARY_PATH, and finally hanging on Cairo-0.92 installation with > > This module requires ExtUtils::Depends to install itself. > Install ExtUtils::Depends from CPAN? [y] > > in the log. I gave up. > > So I installed the perl stuff via my distro means, except for Gtk2-1.141 that I > downloaded from CPAN. For > > 1. My distro's pango-1.14.6 package > 2. Package I built from pango-1.14.7 source > 3. Package I built from pango-1.14.8 source > > I did in Gtk2-1.141 source directory: > > make clean > perl Makefile.PL > make > make test > > The test is IMO a bit strange because it depends on X server running (therefore > the reproducibility for different people is probably poor), but anyway, I got > identical outputs (except the timing) in all three cases, a few Gdk-CRITICALs > and the following summary: > > All tests successful (54 subtests UNEXPECTEDLY SUCCEEDED), 2 tests and 57 > subtests skipped. > Files=198, Tests=3982, 27 wallclock secs (18.09 cusr + 4.52 csys = 22.61 CPU) > > So: how does someone else reproduce the problem? > First of all, you can file a bug against AppsFromScratch: http://appsfromscratch.berlios.de/ -> "Mailing lists: http://developer.berlios.de/mail/?group_id=6867" -> http://developer.berlios.de/bugs/?group_id=6867 -> (Submit A Bug) -> http://developer.berlios.de/bugs/?func=addbug&group_id=6867 . Second, I am about to upload the latest unreleased version I am currently using, and I write how to use it - you have now a possibility to specify targets to be built on command line.
(In reply to comment #14) > > Some of the things > we bind can't really be tested without actually trying them out... I agree, but the run-time behaviour of Gtk+ depends on quite a few unknown factors that may be hard to disentangle... Well, this is not this bug is about, although it can be affected by this problem. Who knows how for example Sergei's and my environments differ and how it can affect the test outcome.
Created attachment 77146 [details] the latest tarball of AppsFromScratch The command line in 'sh' syntax should be something like ~/AppsFromScratch/20061104/bin/build.pl -targets_to_build Gtk2 -make_like -check_with_ldd 1>build.log 2>&1 &
About > > This module requires ExtUtils::Depends to install itself. > > Install ExtUtils::Depends from CPAN? [y] > > > > in the log. I gave up. I have ExtUtils::Depends installed at system level, so the build process finds it. If it isn't installed, and you do not wish to install it (the module is harmless), I can modify 'default_build_data_sub.prl' in a manner it will build and install this module too. But this means I'll have to also write in 'default_build_data_sub.prl' that gtk2/gnome PErl bindings depend on this module explicitly - not a big deal. If you have really strong objections to having ExtUtils::Depends installed at system level, please let me know.
(In reply to comment #18) > If you have really strong objections to having ExtUtils::Depends installed at > system level, please let me know. No, the trouble is 1. All the involved things have their configures and Makefile.PLs that check for their dependencies and they make pretty obvious something is missing. When built via appsfromscratch it just hangs instead, one has to terminate it and look into some log, that's hardly an improvement. 2. Leaving aside automatic detection, it's not even written in the README what is required.
(In reply to comment #17) > the latest tarball of AppsFromScratch > > The command line in 'sh' syntax should be something like > > ~/AppsFromScratch/20061104/bin/build.pl -targets_to_build Gtk2 -make_like > -check_with_ldd 1>build.log 2>&1 & I tried this, but perhaps a bad day, it didn't succeed either. This time it could not find gettext-0.16 on any mirror it tried. So I gave up again, and tried the procedure described above in a different distro (this time Ubuntu), where system pango was 1.14.5, the manually compiled ones were again 1.14.7 and 1.14.8. The test results were again identical for all three versions. I got one failure t/GtkSocket-GtkPlug................ok 1/4The program 'GtkSocket-GtkPlug.t' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 173 error_code 3 request_code 152 minor_code 1) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) in all three cases which can be related to the fact X11 was tunelled over SSH. Note in these reproduction attempts, the pango package tested is always the *only* present in the system (in a location where it can be found by the linker anyway). I'm not sure appsfromscratch can ensure that -- in that case it's questionable what it actually tests.
(In reply to comment #20) > (In reply to comment #17) > > the latest tarball of AppsFromScratch > > > > The command line in 'sh' syntax should be something like > > > > ~/AppsFromScratch/20061104/bin/build.pl -targets_to_build Gtk2 -make_like > > -check_with_ldd 1>build.log 2>&1 & > > I tried this, but perhaps a bad day, it didn't succeed either. This time it > could not find gettext-0.16 on any mirror it tried. > At the moment: " lftp gd.tuwien.ac.at:/gnu/gnusrc/gettext> ls -lt gettext-0.16.tar.gz -rw-r--r-- 1 ftp ftp 8546162 Oct 26 23:05 gettext-0.16.tar.gz " - the mirror is in the list. Are you absolutely sure gettext-0.16.tar.gz could not be found on any of 135 GNU mirrors listed in AppsFromScratch/20061104/include/perl/project_specific/default_build_data_sub.prl file ? The script is supposed to try them all in the end, that is, it tries until the tarball is found or all possibilities are exhausted. This can take long, but, I believe, it should work the way I described it. ... Anyway, I'm "glad" you had the failure you've described. I had similar failures running the stuff on my other machine through ssh, but it was difficult to reproduce the failures, so I didn't file bug reports. This problem was observed on local machine.
I just fixed the original problem with the GtkItemFactory test in our CVS repository.