On 2008-03-13 15:23+1030 Jonathan Woithe wrote:

> I suspect there might be some issue going on between the different versions
> of plplot on your system.  It would be nice to pinpoint the exact cause.

Hazen and Hez may be comparing apples and oranges.

One result is the build-tree result.  By design, everything there (including
our dynamically loaded devices) should refer to PLplot results that are
resident in the build tree so that you have a pure build-tree result with no
confusion from other PLplot libraries that are located elsewhere. This rule
is enforced automatically by CMake using the rpath mechanism on Linux. On
Mac OS X, apparently there is no equivalent to rpath so to get a pure
build-tree result you must use something like LD_LIBRARY_PATH (whose Mac OS
X variant name I always forget) to enforce that rule, and it is
complicated because the PLplot libraries are located in a variety of
locations in the build tree.

Another result is the install-tree result.  Again by design, everything
there (including our dynamically loaded devices) should refer to PLplot
results that are resident in the install tree in order to have a pure
install-tree result with no confusion from other PLplot libraries that are
located elsewhere.  On Linux this rule is enforced with rpath, but the user
must do that for themselves on Mac OS X.  In general the layout of the
install-tree is pretty straightforward (all libraries occur in the same
directory) so it is an easier situation to debug.

The other point I want to make concerns segfaults which are defined as
follows (by wikipedia): "A segmentation fault occurs when a program attempts
to access a memory location that it is not allowed to access, or attempts to
access a memory location in a way that is not allowed".
http://en.wikipedia.org/wiki/Access_violation gives several straightforward
ways you can get those from C, but they miss the big one which is memory
management issues (i.e., reading or writing beyond the alloc'd memory)
causing an indirect segfault.  As I understand it such memory management
issues do not directly cause a segfault, but they do cause you to overwrite
neighbouring alloc'd areas, and when you attempt to use pointers from those
overwritten areas, you end up accessing the wrong memory which often, _but
not always_ causes a segfault.

The point is that segfaults indirectly caused by memory management issues
depend critically on memory layout. So you can have memory management issues
with no segfaults or any other symptoms until you make some trivial change
to your code.  For example, I have seen them come and go for an early
incarnation of our gd device driver that had memory management problems. I
remember it well because it was such a frustrating situation; the segfault
appeared in normal operation, but if I put in a print statement or even
attempted to debug with gdb, the segfault disappeared again!  Eventually, 
using valgrind I tracked down the problem to a premature free of memory that
gd was still using.

Here is my advice for dealing with the current cairo issue.

(1) Use the install-tree version of PLplot (with a unique prefix so nothing
else is mixed in) and check the cairo dynamic device in that install tree
with ldd to make sure all PLplot libraries that are linked in are found in
that unique install tree.  Avoid the build-tree version of PLplot since the
PLplot libraries that are built are scattered all over that build tree so it
is a much more complicated situation than what you will find in the install

(2) Use valgrind to debug the problem comparing results from -dev psttfc and
pscairo.  Use the gcc -g compile option so that you can get PLplot
source-code line numbers from valgrind when it informs you about memory
management issues. psttfc actually refers to many of the same external
libraries as pscairo so comparing results for those two devices with
valgrind and then comparing the source code for the two device drivers is
probably the most efficient way to find the answer.

Good luck!

Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project

Linux-powered Science

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Plplot-devel mailing list

Reply via email to