'make check' fails ... on some machines

[Jari Häkkinen]

One test fails on my mac

===========================================
   svndigest 0.8pre: test/test-suite.log   
===========================================

1 of 18 tests failed.  

.. contents:: :depth: 2


FAIL: repo_test.sh (exit: 1)
============================

The same failure is found on Linux Fedora 13. The tests pass on some machines; a mac and a linux box running Fedora 11.

When svg is generated instead of png the tests runs successfully. plplot support several formats on my 64bit mac (xwin, tk, ps, psc, xfig, null, tkwin, mem, svg, xcairo, pdfcairo, pscairo, pscairo, svgcairo, pngcairo, extcairo). I tested several of the formats and only the cairo variants fails tests. There must be something wrong with the cairo driver.

There is a ticket in the ​plplot dev site reporting similar problems as we see ​BUG: cairo drivers crash - ID: 3009045 and ​mail thread.

Installed pango and cairo versions (macports.org versions for macs) and test status:

	Mac (Intel 64bit)	Mac Gx	Fedora 11 (64bit)	Fedora 13 (32bit)
test	Failure	Success	Success	Failure
pango	@1.24.5_0+macosx	@1.24.5_0+macosx	1.24.5-1.fc11	1.28.0-1.fc13
cairo	@1.8.8_0 @1.8.10_0+macosx	@1.8.10_0 @1.8.10_0+macosx	1.8.8-1.fc11	1.8.10-1.fc13

After extensive debugging I think I found the problem. It has to do with ​GObjects in pango. The problem seems to be that the "constructor" is not run the second time the pango_cairo fontmap is needed. A null pointer is used since the error is not catched in plplot. So, is this a plplot, glib or pango problem?

[Jari Häkkinen]

On mu mac I get this stack trace

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000090
0x0000000100fa021a in pango_layout_clear_lines ()
(gdb) bt
#0  0x0000000100fa021a in pango_layout_clear_lines ()
#1  0x0000000100fa02b1 in pango_layout_context_changed ()
#2  0x00000001009f2b74 in plD_esc_cairo ()
#3  0x000000010021bcae in plP_esc ()
#4  0x000000010021c709 in plP_text ()
#5  0x000000010023d319 in c_plmtex ()
#6  0x0000000100214077 in c_plaxes ()
#7  0x0000000100031ea3 in std::string::_M_data () at Graph.cc:112
#8  0x0000000100031ea3 in std::string::c_str () at 
/usr/include/c++/4.2.1/bits/basic_string.h:1533
#9  0x0000000100031ea3 in theplu::svndigest::Graph::plot 
(this=0x7fff5fbfdfb0, y=@0x100a32b08, label=@0x100a32b00, lines=515) at 
Graph.cc:113
#10 0x0000000100047e04 in theplu::svndigest::Stats::plot 
(this=0x100a18ad0, filename=<value temporarily unavailable, due to 
optimizations>, linetype=<value temporarily unavailable, due to 
optimizations>, format=<value temporarily unavailable, due to 
optimizations>) at Stats.cc:481
#11 0x0000000100048118 in theplu::svndigest::Stats::plot 
(this=0x100a18ad0, filename=@0x7fff5fbfe610, linetype=@0x7fff5fbfed60) 
at Stats.cc:410
#12 0x000000010002048f in theplu::svndigest::Directory::print_core 
(this=0x7fff5fbff2d0, stats_type=@0x100a181e0, user=@0x7fff5fbfed70, 
line_type=@0x7fff5fbfed60, log=@0x100a27280) at Directory.cc:190
#13 0x000000010003d322 in theplu::svndigest::Node::print 
(this=0x7fff5fbff2d0, verbose=true) at Node.cc:205
#14 0x0000000100007c28 in write_report (option=@0x7fff5fbfef30, 
repo=<value temporarily unavailable, due to optimizations>, 
tree=@0x7fff5fbff2d0, stats=@0x7fff5fbff2f0) at svndigest.cc:228
#15 0x000000010000830e in main (argc=<value temporarily unavailable, due 
to optimizations>, argv=<value temporarily unavailable, due to 
optimizations>) at svndigest.cc:110

[Jari Häkkinen]

Linux gives this stack trace

Program received signal SIGSEGV, Segmentation fault.
0x00b10370 in pthread_mutex_trylock () from /lib/libpthread.so.0
(gdb) bt
#0  0x00b10370 in pthread_mutex_trylock () from /lib/libpthread.so.0
#1  0x0024416e in ?? () from /lib/libgthread-2.0.so.0
#2  0x0048248e in g_slice_alloc () from /lib/libglib-2.0.so.0
#3  0x0043ca8a in g_array_sized_new () from /lib/libglib-2.0.so.0
#4  0x0043cbb8 in g_array_new () from /lib/libglib-2.0.so.0
#5  0x0048e78f in g_static_private_set () from /lib/libglib-2.0.so.0
#6  0x004962ec in g_get_charset () from /lib/libglib-2.0.so.0
#7  0x00485e10 in g_strerror () from /lib/libglib-2.0.so.0
#8  0x00243df7 in ?? () from /lib/libgthread-2.0.so.0
#9  0x0048efd7 in g_thread_init_glib () from /lib/libglib-2.0.so.0
#10 0x002444f9 in g_thread_init () from /lib/libgthread-2.0.so.0
#11 0x003b4a5c in g_type_init_with_debug_flags () from 
/lib/libgobject-2.0.so.0
#12 0x003b4b13 in g_type_init () from /lib/libgobject-2.0.so.0
#13 0x004232d8 in pango_cairo_font_map_new ()
    from /usr/lib/libpangocairo-1.0.so.0
#14 0x0042332d in pango_cairo_font_map_get_default ()
    from /usr/lib/libpangocairo-1.0.so.0
#15 0x00421bf7 in pango_cairo_create_context ()
    from /usr/lib/libpangocairo-1.0.so.0
#16 0x00421c8a in pango_cairo_create_layout ()
    from /usr/lib/libpangocairo-1.0.so.0
#17 0x0022cbf8 in plD_esc_cairo () from 
/usr/lib/plplot5.9.5/driversd/cairo.so
#18 0x0015f113 in plP_esc () from /usr/lib/libplplotd.so.9
#19 0x00161107 in plP_text () from /usr/lib/libplplotd.so.9
#20 0x0017fd8a in c_plmtex () from /usr/lib/libplplotd.so.9
#21 0x00154310 in c_plaxes () from /usr/lib/libplplotd.so.9
#22 0x00155e3b in c_plbox () from /usr/lib/libplplotd.so.9
#23 0x0028df29 in plstream::box(char const*, double, int, char const*, 
double, int) () from /usr/lib/libplplotcxxd.so.9
#24 0x08073177 in theplu::svndigest::Graph::plot (this=0xbfffe89c,
     y=std::vector of length 71, capacity 71 = {...}, label="jari", 
lines=63)
     at ../../lib/Graph.cc:112
#25 0x08088c39 in theplu::svndigest::Stats::plot (this=0x813b7b0, filename=
     "blame/images/total/lib/Node.h", linetype="total", format="png")
     at ../../lib/Stats.cc:481
#26 0x08088e55 in theplu::svndigest::Stats::plot (this=0x813b7b0, filename=
     "blame/images/total/lib/Node.h", linetype="total")
     at ../../lib/Stats.cc:410
#27 0x0806960f in theplu::svndigest::File::print_core (this=0x813c258,
     stats_type="blame", user="all", line_type="total", log=...)
     at ../../lib/File.cc:382
#28 0x0807a468 in theplu::svndigest::Node::print (this=0x813c258, 
verbose=true)
     at ../../lib/Node.cc:205
#29 0x08063536 in theplu::svndigest::Directory::print_core (this=0x81347b0,
     verbose=true) at ../../lib/Directory.cc:154
#30 0x0807ab52 in theplu::svndigest::Node::print (this=0x81347b0, 
verbose=true)
     at ../../lib/Node.cc:217
#31 0x08063536 in theplu::svndigest::Directory::print_core 
(this=0xbffff1f4,
     verbose=true) at ../../lib/Directory.cc:154
#32 0x0807ab52 in theplu::svndigest::Node::print (this=0xbffff1f4,
     verbose=true) at ../../lib/Node.cc:217
#33 0x08053f40 in write_report (option=..., repo=
     "file:///home/peter/projects/pristine/svndigest-stable/test/repo",
     tree=..., stats=...) at ../../bin/svndigest.cc:228
#34 0x08054749 in main (argc=Cannot access memory at address 0x0
) at ../../bin/svndigest.cc:110

[Jari Häkkinen]

On mac the crash comes when the second png files is created wheras linux generates more than 300 png files. The problem disappears when I run the test on my mac but create svg files. Result of test when creating svg on linux is unknown.

[Peter Johansson]

Note, the Fedora 13 machine runs plplot 5.9.5 (plplot-5.9.5-7.fc13), which might be a problem. As of r1161 we require 5.9.6 so currently the fedora 13 machine is not running the test (well configure is aborted).

[Jari Häkkinen]

With the current state of plplot, pango, cairo, and dynamic loading of drivers I think we got a show stopper. The issue seems to be the dynamic loading and unloading of drivers. I made a test as suggested in the mail thread ​http://www.mail-archive.com/plplot-devel@lists.sourceforge.net/msg01299.html where I removed code unloading the cairo driver in the plplot library. This makes the svndigest test to pass successfully. However, I do not now if resources are wasted with the hack. Even if the issues is resolved by the plplot team, it is not even sure if it is their problem, the push of the resolution will take some time. The mail thread was opened already in 2008 and the problem is not fixed yet.

Maybe we should require another png-generating library and deprecate cairo/pango?

[Peter Johansson]

Replying to jari:

Maybe we should require another png-generating library and deprecate cairo/pango?

Sorry, I'm not sure I understand the options here. Do you mean that we should drop plplot (i.e. reopen ticket:97) or is there a way to use plplot and prevent usage of cairo/pango?

Needless to say, waiting for this bug to be fixed, is not an option.

[Jari Häkkinen]

Replying to peter:

Replying to jari:

Maybe we should require another png-generating library and deprecate cairo/pango?

Sorry, I'm not sure I understand the options here. Do you mean that we should drop plplot (i.e. reopen ticket:97) or is there a way to use plplot and prevent usage of cairo/pango?

I was mislead by the port file for plplot. The file was stating a dependency to libpng but there is no direct dependency. (If there is a dependency to libpng then it is through pango.) My thinking was that we could make plplot to use another png driver rather than the pngcairo driver (similarly to the svg and svgcairo driver). Well, it turns out that the pnggd driver is deprecated since long. So, there is no png without pango/cairo.

Needless to say, waiting for this bug to be fixed, is not an option.

Yeah, the problem is that then we must throw out plplot ... if we cannot persuade them to make a quick release. I am still looking for a solution but it doesn't look promising.

[Peter Johansson]

Replying to jari:

Yeah, the problem is that then we must throw out plplot ...

My gut says we should replace plplot with GNU libplot (see ticket #97).

[Jari Häkkinen]

Replying to peter:

Replying to jari:

Yeah, the problem is that then we must throw out plplot ...

My gut says we should replace plplot with GNU libplot (see ticket #97).

The problem is that I don't like the way plotutils is marketed and maintained. The ​project page claims that the latest version is 2.4.1 from 2000 and several links are broken even when the page is claimed to be updated in 2010. The only strength it has is that it has its project at gnu.org and was accepted as a GNU project some time ago. We could accept it at face value since it is a GNU project but I am not convinced. Also, I think plotutils generates ugly plots. It seems like plplot wasn't the wisest choice but I am working on a kludge around the problem of dynamic loading.

[Jari Häkkinen]

Replying to jari:

The problem is that I don't like the way plotutils is marketed and maintained. The ​project page claims that the latest version is 2.4.1 from 2000 ....

The actual latest version is 2.6 from 2009.

[Peter Johansson]

Just speculating, but this sounds as though the problem is when number of plstreams goes down to zero and then later up to one again. If we could avoid the problem by always have a positive number of plstreams active that would be a reasonable workaround, which we could implement by e.g. having a dummie plstream in main.

[Jari Häkkinen]

Replying to peter:

Just speculating, but this sounds as though the problem is when number of plstreams goes down to zero and then later up to one again. If we could avoid the problem by always have a positive number of plstreams active that would be a reasonable workaround, which we could implement by e.g. having a dummie plstream in main.

You are right because then plend is never called (at least not until main exits) and consequently the dynamic pango/cairo libraries will stay in memory. However, inspired by Icarus I am trying to resolve the underlying issue. If I find it, I can submit a patch, we use the kludge and wait for a new release of plplot (or pango if the problem is there).

[Jari Häkkinen]

Ok, after many hours learning how awkward it is to program object oriented C ... you have to implement everything that a C++ compiler does. Looking at the pango code was interesting and I suppose that if one has to work with C then the C struct object design is what one ends up with. Anyhow, I tried to create dynamically loaded types but failed to load them dynamically. I suppose it was due to me but there is a small chance that it is actually Mac OS X and libtool issue. What seems to be trivial in linux is not so in macs. I didn't try to find a work around for the libtool problems.

So, like Icarus, I crashed.

[Jari Häkkinen]

(In [1170]) Fixes #469 and addresses #472. Work around for problem with multiple plot generation using pango.