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 tree. (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 __________________________ 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 (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
