After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 378662 - introduction of pango-1.14.8 makes 'make test' of Gtk2-1.141 to fail; with pango-1.14.7 - OK
introduction of pango-1.14.8 makes 'make test' of Gtk2-1.141 to fail; with pa...
Status: RESOLVED FIXED
Product: gnome-perl
Classification: Bindings
Component: Gtk2
unspecified
Other All
: Normal normal
: ---
Assigned To: gtk2-perl-bugs
gtk2-perl-bugs
Depends on:
Blocks:
 
 
Reported: 2006-11-23 23:27 UTC by Sergei Steshenko
Modified: 2008-08-17 18:35 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
screen output of the failing 'make test' (26.72 KB, text/plain)
2006-11-23 23:28 UTC, Sergei Steshenko
Details
screen output of 'make test' which is OK (26.38 KB, text/plain)
2006-11-23 23:30 UTC, Sergei Steshenko
Details
Makefile of failing 'make test' of Gtk2-1.141 (159.32 KB, text/plain)
2006-11-23 23:33 UTC, Sergei Steshenko
Details
Makefile of Gtk2-1.141 for which 'make test' is OK (159.32 KB, text/plain)
2006-11-23 23:34 UTC, Sergei Steshenko
Details
the latest tarball of AppsFromScratch (55.26 KB, application/x-compressed-tar)
2006-11-25 22:59 UTC, Sergei Steshenko
Details

Description Sergei Steshenko 2006-11-23 23:27:26 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.
Comment 1 Sergei Steshenko 2006-11-23 23:28:53 UTC
Created attachment 77080 [details]
screen output of the failing 'make test'
Comment 2 Sergei Steshenko 2006-11-23 23:30:17 UTC
Created attachment 77081 [details]
screen output of 'make test' which is OK
Comment 3 Sergei Steshenko 2006-11-23 23:33:09 UTC
Created attachment 77082 [details]
Makefile of failing 'make test' of Gtk2-1.141
Comment 4 Sergei Steshenko 2006-11-23 23:34:32 UTC
Created attachment 77083 [details]
Makefile of Gtk2-1.141 for which 'make test' is OK
Comment 5 Behdad Esfahbod 2006-11-24 01:01:07 UTC
I don't see anything Pango related to the failure.
Comment 6 Sergei Steshenko 2006-11-24 01:28:04 UTC
(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.
Comment 7 Behdad Esfahbod 2006-11-24 17:12:03 UTC
So, maybe you can look at the test to see what it's doing?
Comment 8 Sergei Steshenko 2006-11-24 19:55:43 UTC
(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.
Comment 9 Behdad Esfahbod 2006-11-24 21:07:34 UTC
(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.
Comment 10 muppet 2006-11-24 21:34:29 UTC
(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.
Comment 11 Sergei Steshenko 2006-11-25 04:48:18 UTC
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.
Comment 12 Behdad Esfahbod 2006-11-25 04:55:11 UTC
> < 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.
Comment 13 Yeti 2006-11-25 20:12:35 UTC
(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?
Comment 14 muppet 2006-11-25 22:46:37 UTC
(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...
Comment 15 Sergei Steshenko 2006-11-25 22:55:37 UTC
(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.
Comment 16 Yeti 2006-11-25 22:59:27 UTC
(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.
Comment 17 Sergei Steshenko 2006-11-25 22:59:28 UTC
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 &
Comment 18 Sergei Steshenko 2006-11-25 23:06:13 UTC
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.


Comment 19 Yeti 2006-12-03 11:55:25 UTC
(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.

Comment 20 Yeti 2006-12-03 12:04:41 UTC
(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.
Comment 21 Sergei Steshenko 2006-12-03 12:42:33 UTC
(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.
Comment 22 Torsten Schoenfeld 2008-08-17 18:35:52 UTC
I just fixed the original problem with the GtkItemFactory test in our CVS repository.