Re: [Plplot-devel] xcairo segmentation fault
On Oct 25, 2008, at 4:56 PM, Hezekiah M. Carty wrote: > While testing trying to patch the recently discussed multiple output > streams with the same driver bug I found something that is possibly > useful for diagnosing this Cairo segmentation fault issue, and > certainly useful as a workaround otherwise. If plend is only called > after all plotting is complete and calls to plend1 are used between > plots then no segfaults seem to occur. > > Example: > > plsdev "xcairo" > plinit () > plenv 0.0 1.0 0.0 1.0 1 0 > plend1 () > plsdev "xcairo" > plinit () > plenv 0.0 1.0 0.0 1.0 1 0 > plend1 () > ... > plend () > > In this case, no segfault occurs on my system (Ubuntu Hardy, 64bit, > latest PLplot SVN). The segfault still occurs if I replace the > "plend1" calls with "plend". > > Hope this helps, either as an indicator of where the problem > originates or simply as a relatively simple workaround. Thanks for the observation! I'm not sure if I am any closer to actually figuring it out but I believe the problem might be a shared libraries (or libltdl) issue. One difference between plend and plend1 is the call to lt_dlexit() in plend(). If this is commented out then the segfault goes away. Also, if you set ENABLE_DYNDRIVERS=OFF and rebuild then the test program will not segfault. Perhaps there is some issue with the same executable loading and unloading dynamic modules multiple times on some machines, or with some versions of libltdl? Or perhaps it is specific to the Cairo library? -Hazen - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xcairo segmentation fault
On Wed, Mar 19, 2008 at 9:51 PM, Hazen Babcock <[EMAIL PROTECTED]> wrote: > Agreed, but the segfault occurs because I did not think to check the > return value of the function pango_cairo_create_layout(). It should > return a pointer to a PangoLayout, but when it fails, as it does in > our test case, it returns NULL. The program crashes when this null > pointer is passed to the next function which expects a valid > PangoLayout pointer. I can add a test for this and the program will > no longer segfault, but this does not solve the problem of why > pango_cairo_create_layout() is failing in the first place. Presumably > it is trying to tell us something with the message: > > (process:10860): GLib-GObject-WARNING **: cannot register existing > type `PangoCairoFcFontMap' > > Or maybe this could just mean that at some other point we are > overwriting some crucial bit of memory? > > Unfortunately I have not been able to trigger this bug using a simple > cairo/pango program that contains just the apparently problematic > function calls. While testing trying to patch the recently discussed multiple output streams with the same driver bug I found something that is possibly useful for diagnosing this Cairo segmentation fault issue, and certainly useful as a workaround otherwise. If plend is only called after all plotting is complete and calls to plend1 are used between plots then no segfaults seem to occur. Example: plsdev "xcairo" plinit () plenv 0.0 1.0 0.0 1.0 1 0 plend1 () plsdev "xcairo" plinit () plenv 0.0 1.0 0.0 1.0 1 0 plend1 () ... plend () In this case, no segfault occurs on my system (Ubuntu Hardy, 64bit, latest PLplot SVN). The segfault still occurs if I replace the "plend1" calls with "plend". Hope this helps, either as an indicator of where the problem originates or simply as a relatively simple workaround. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xcairo segmentation fault
On Wed, Mar 19, 2008 at 9:51 PM, Hazen Babcock <[EMAIL PROTECTED]> wrote: > Agreed, but the segfault occurs because I did not think to check the > return value of the function pango_cairo_create_layout(). It should > return a pointer to a PangoLayout, but when it fails, as it does in > our test case, it returns NULL. The program crashes when this null > pointer is passed to the next function which expects a valid > PangoLayout pointer. I can add a test for this and the program will > no longer segfault, but this does not solve the problem of why > pango_cairo_create_layout() is failing in the first place. Presumably > it is trying to tell us something with the message: > > (process:10860): GLib-GObject-WARNING **: cannot register existing > type `PangoCairoFcFontMap' > > Or maybe this could just mean that at some other point we are > overwriting some crucial bit of memory? This error does not occur on my Fedora 9 64bit installation, using the latest PLplot from Subversion. It does still occur on my Ubuntu Hardy 64bit install though. Ubuntu library versions: Cairo 1.6.0 Pango 1.20.5 Fedora library versions: Cairo 1.6.4 Pango 1.20.1 The library versions are similar, if not the same, between the two distributions. I have not used either Pango or Cairo directly, but I would be happy to do some testing here if you have any suggestions about what might help diagnose this problem. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xcairo segmentation fault
On May 19, 2008, at 6:12 PM, Hezekiah M. Carty wrote: > On Wed, Mar 19, 2008 at 9:51 PM, Hazen Babcock <[EMAIL PROTECTED]> > wrote: >> >> Agreed, but the segfault occurs because I did not think to check the >> return value of the function pango_cairo_create_layout(). It should >> return a pointer to a PangoLayout, but when it fails, as it does in >> our test case, it returns NULL. The program crashes when this null >> pointer is passed to the next function which expects a valid >> PangoLayout pointer. I can add a test for this and the program will >> no longer segfault, but this does not solve the problem of why >> pango_cairo_create_layout() is failing in the first place. > > Is there a work-around for this problem? I would like to use the > Cairo output drivers to generate a series of plots, but this problem > is preventing me from doing so. > > I see that the example plots on the web site are made with using > family files. I would like to be able to use arbitrary file names for > each plot in this sequence, not just "foo-1.png" then "foo-2.png" etc. > Is there a way to do this without using plend between plots? I have not made any progress on determining what is going wrong. All I can suggest is that you use the family functionality and then rename the plots when you are done. -Hazen - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xcairo segmentation fault
On Wed, Mar 19, 2008 at 9:51 PM, Hazen Babcock <[EMAIL PROTECTED]> wrote: > > Agreed, but the segfault occurs because I did not think to check the > return value of the function pango_cairo_create_layout(). It should > return a pointer to a PangoLayout, but when it fails, as it does in > our test case, it returns NULL. The program crashes when this null > pointer is passed to the next function which expects a valid > PangoLayout pointer. I can add a test for this and the program will > no longer segfault, but this does not solve the problem of why > pango_cairo_create_layout() is failing in the first place. Is there a work-around for this problem? I would like to use the Cairo output drivers to generate a series of plots, but this problem is preventing me from doing so. I see that the example plots on the web site are made with using family files. I would like to be able to use arbitrary file names for each plot in this sequence, not just "foo-1.png" then "foo-2.png" etc. Is there a way to do this without using plend between plots? Thank you for your time, Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xcairo segmentation fault
On Mar 13, 2008, at 2:42 AM, Alan W. Irwin wrote: > 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. Agreed, but the segfault occurs because I did not think to check the return value of the function pango_cairo_create_layout(). It should return a pointer to a PangoLayout, but when it fails, as it does in our test case, it returns NULL. The program crashes when this null pointer is passed to the next function which expects a valid PangoLayout pointer. I can add a test for this and the program will no longer segfault, but this does not solve the problem of why pango_cairo_create_layout() is failing in the first place. Presumably it is trying to tell us something with the message: (process:10860): GLib-GObject-WARNING **: cannot register existing type `PangoCairoFcFontMap' Or maybe this could just mean that at some other point we are overwriting some crucial bit of memory? Unfortunately I have not been able to trigger this bug using a simple cairo/pango program that contains just the apparently problematic function calls. -Hazen - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xcairo segmentation fault
On Thu, Mar 13, 2008 at 12:53 AM, Jonathan Woithe <[EMAIL PROTECTED]> wrote: > > On Wed, Mar 12, 2008 at 11:12 PM, Jonathan Woithe > > <[EMAIL PROTECTED]> wrote: > > > I agree. What about running ldd on /lib/plplot-*/cairo.so? > > > Anything differences in this between the two working directories? > > > > > > The drivers are loaded dynamically on demand I think which is why the > cairo > > > libraries (for example) aren't explicitly required by the test > application. > > > > This looks like it may be the culprit, though I don't know why. > > > > from the segfaulting location: > > ~/Projects/ocaml/tmp$ ldd > ~/Applications/plplot/lib/plplot5.9.0/driversd/cairo.so > > > libplplotd.so.9 => /usr/lib/libplplotd.so.9 (0xb7f16000) > > > libcsirocsa.so.0 => ~/Applications/plplot/lib/libcsirocsa.so.0 > > (0xb7e6d000) > > libcsironn.so.0 => ~/Applications/plplot/lib/libcsironn.so.0 > (0xb7e65000) > > > > > from the build directory (no segfaults): > > ~/tmp/BUILD/plplot/plplot-svn/build/drivers$ ldd cairo.so > > > libplplotd.so.9 => > > ~/tmp/BUILD/plplot/plplot-svn/build/src/libplplotd.so.9 (0xb7eda000) > > > libcsirocsa.so.0 => > > ~/tmp/BUILD/plplot/plplot-svn/build/lib/csa/libcsirocsa.so.0 (0xb7bd7000) > > libcsironn.so.0 => > ~/tmp/BUILD/plplot/plplot-svn/build/lib/nn/libcsironn.so.0 (0xb7bcf000) > > > > > ~/Applications/plplot/* is my plplot-svn install, while /usr/lib/* > > holds the Debian packages. > > How do you normally switch between these two plplot environments? Do you > use LD_LIBRARY_PATH? If so, was it active for any of the above tests? LD_LIBRARY_PATH was set in both cases to $HOME/Applications/plplot/lib > What command line did you use to compile the test application? The test was in OCaml, one was in octave. I don't know if it will help much, but the compilation command was: ocamlfind ocamlopt -package plplot -linkpkg -o plot.native plot.ml I checked the relevant files for the OCaml -> C PLplot interface and they all point (according to ldd) to the ~/Applications/plplot/lib/ files. > I guess I'm curious to know how the compiler knows which of these to use > when compiling and linking your test application. There is also the small > matter of how your test application seemingly correctly picks > libplplotd.so.9 from ~/Applications/plplot/lib/ in both cases - this puzzles > me a bit. pkg-config is used to find the appropriate compilation flags. For compiling the OCaml PLplot interface I use pkg-config, with PKG_CONFIG_PATH=$HOME/Applications/plplot/lib/pkgconfig:$PKG_CONFIG_PATH. A test of pkg-config --libs plplotd gives the expected results, pointing to the files under ~. > In the above, the libplplotd.so.9 is found in the build directory in the > second test because the uninstalled cairo.so probably has a hardcoded path > to it; this might be done to assist in debugging as it allows one to run > things from the build directory without installing. > > The situation in the first test is a concern since the wrong libplplot.so > is found. What's not clear is why, given that the ~/Applications/ version > is located by the test application. This seems to be confirmed by Alan's reply. > > Is there a way to make LD_LIBRARY_PATH or similar hold for the dynamically > > loaded cairo.so? > > In theory at least LD_LIBRARY_PATH should be consulted when loading cairo.so > unless the underlying application is a setuid or setgid binary. Refer to > the dlopen() manpage for details. > > I've just checked the plplot source code. The call to dlopen() uses a path > to the driver which is returned by plGetDrvDir() in plcore.c. If you are > anywhere in the build tree then the directory is forced to refer to the > driver's directory in the build tree. If not, it tries to find the driver > in the following places: > > * The directory specified by the PLPLOT_DRV_DIR environment variable > * The ultimate install location of the drivers > > This explains how the driver itself is found. Resolving the driver's > dependencies should occur as previously explained. > > 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. > > Regards > jonathan > Any suggestions on how to further track this down? If I have left out anything that can help please let me know. If I remove the installed plplot-svn from ~/Applications/plplot/ and unset PKG_CONFIG_PATH and LD_LIBRARY_PATH, I still get the segmentation fault building everything against the Debian Sid PLplot packages. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
Re: [Plplot-devel] xcairo segmentation fault
> > 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. I agree. The circumstances on the systems are different and I suspect that the root causes may be different. It's possible Hezekiah's problem is related to the multiple installs of plplot lying around; certainly the ldd results are a little odd. That's not to say that there isn't/wasn't a memory corruption/overwrite/misuse issue occurring as well. > The other point I want to make concerns segfaults ... gives several > straightforward ways you can get those from C, but they miss the big one > which is memory management issues ... The point is that segfaults > indirectly caused by memory management issues depend critically on memory > layout Correct, and as such they can be cows to track down. Adding debug code for example an appear to make the problem disappear. Regards jonathan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xcairo segmentation fault
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/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xcairo segmentation fault
> On Wed, Mar 12, 2008 at 11:12 PM, Jonathan Woithe > <[EMAIL PROTECTED]> wrote: > > I agree. What about running ldd on /lib/plplot-*/cairo.so? > > Anything differences in this between the two working directories? > > > > The drivers are loaded dynamically on demand I think which is why the cairo > > libraries (for example) aren't explicitly required by the test application. > > This looks like it may be the culprit, though I don't know why. > > from the segfaulting location: > ~/Projects/ocaml/tmp$ ldd > ~/Applications/plplot/lib/plplot5.9.0/driversd/cairo.so > libplplotd.so.9 => /usr/lib/libplplotd.so.9 (0xb7f16000) > libcsirocsa.so.0 => ~/Applications/plplot/lib/libcsirocsa.so.0 > (0xb7e6d000) > libcsironn.so.0 => ~/Applications/plplot/lib/libcsironn.so.0 > (0xb7e65000) > > from the build directory (no segfaults): > ~/tmp/BUILD/plplot/plplot-svn/build/drivers$ ldd cairo.so > libplplotd.so.9 => > ~/tmp/BUILD/plplot/plplot-svn/build/src/libplplotd.so.9 (0xb7eda000) > libcsirocsa.so.0 => > ~/tmp/BUILD/plplot/plplot-svn/build/lib/csa/libcsirocsa.so.0 (0xb7bd7000) > libcsironn.so.0 => > ~/tmp/BUILD/plplot/plplot-svn/build/lib/nn/libcsironn.so.0 (0xb7bcf000) > > ~/Applications/plplot/* is my plplot-svn install, while /usr/lib/* > holds the Debian packages. How do you normally switch between these two plplot environments? Do you use LD_LIBRARY_PATH? If so, was it active for any of the above tests? What command line did you use to compile the test application? I guess I'm curious to know how the compiler knows which of these to use when compiling and linking your test application. There is also the small matter of how your test application seemingly correctly picks libplplotd.so.9 from ~/Applications/plplot/lib/ in both cases - this puzzles me a bit. In the above, the libplplotd.so.9 is found in the build directory in the second test because the uninstalled cairo.so probably has a hardcoded path to it; this might be done to assist in debugging as it allows one to run things from the build directory without installing. The situation in the first test is a concern since the wrong libplplot.so is found. What's not clear is why, given that the ~/Applications/ version is located by the test application. > Is there a way to make LD_LIBRARY_PATH or similar hold for the dynamically > loaded cairo.so? In theory at least LD_LIBRARY_PATH should be consulted when loading cairo.so unless the underlying application is a setuid or setgid binary. Refer to the dlopen() manpage for details. I've just checked the plplot source code. The call to dlopen() uses a path to the driver which is returned by plGetDrvDir() in plcore.c. If you are anywhere in the build tree then the directory is forced to refer to the driver's directory in the build tree. If not, it tries to find the driver in the following places: * The directory specified by the PLPLOT_DRV_DIR environment variable * The ultimate install location of the drivers This explains how the driver itself is found. Resolving the driver's dependencies should occur as previously explained. 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. Regards jonathan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xcairo segmentation fault
On Wed, Mar 12, 2008 at 11:12 PM, Jonathan Woithe <[EMAIL PROTECTED]> wrote: > I agree. What about running ldd on /lib/plplot-*/cairo.so? > Anything differences in this between the two working directories? > > The drivers are loaded dynamically on demand I think which is why the cairo > libraries (for example) aren't explicitly required by the test application. This looks like it may be the culprit, though I don't know why. from the segfaulting location: ~/Projects/ocaml/tmp$ ldd ~/Applications/plplot/lib/plplot5.9.0/driversd/cairo.so linux-gate.so.1 => (0xb7f75000) libplplotd.so.9 => /usr/lib/libplplotd.so.9 (0xb7f16000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7ee) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb7ed6000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb7e99000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb7e22000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7de6000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7de2000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7dde000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7d3c000) libSM.so.6 => /usr/lib/libSM.so.6 (0xb7d34000) libICE.so.6 => /usr/lib/libICE.so.6 (0xb7d1d000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb7c31000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb7c23000) libltdl.so.3 => /usr/lib/libltdl.so.3 (0xb7c1c000) libcsirocsa.so.0 => /usr/lib/libcsirocsa.so.0 (0xb7c13000) libcsironn.so.0 => /usr/lib/libcsironn.so.0 (0xb7c0b000) libqhull.so.5 => /usr/lib/libqhull.so.5 (0xb7bbd000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7b4e000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb79f3000) /lib/ld-linux.so.2 (0x8000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb79c5000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb799c000) libz.so.1 => /usr/lib/libz.so.1 (0xb7987000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7964000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb795c000) libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb7934000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb7931000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb792c000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb790c000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb78f3000) from the build directory (no segfaults): ~/tmp/BUILD/plplot/plplot-svn/build/drivers$ ldd cairo.so linux-gate.so.1 => (0xb7f39000) libplplotd.so.9 => ~/tmp/BUILD/plplot/plplot-svn/build/src/libplplotd.so.9 (0xb7eda000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7ea3000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb7e9a000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb7e5d000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb7de6000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7daa000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7da6000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7da1000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7d0) libSM.so.6 => /usr/lib/libSM.so.6 (0xb7cf8000) libICE.so.6 => /usr/lib/libICE.so.6 (0xb7ce1000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb7bf5000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb7be7000) libltdl.so.3 => /usr/lib/libltdl.so.3 (0xb7bdf000) libcsirocsa.so.0 => ~/tmp/BUILD/plplot/plplot-svn/build/lib/csa/libcsirocsa.so.0 (0xb7bd7000) libcsironn.so.0 => ~/tmp/BUILD/plplot/plplot-svn/build/lib/nn/libcsironn.so.0 (0xb7bcf000) libqhull.so.5 => /usr/lib/libqhull.so.5 (0xb7b81000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7b12000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb79b6000) /lib/ld-linux.so.2 (0x8000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb7989000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb796) libz.so.1 => /usr/lib/libz.so.1 (0xb794b000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7928000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb791f000) libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb78f8000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb78f5000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb78f) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb78d) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb78b6000) ~/Applications/plplot/* is my plplot-svn install, while /usr/lib/* holds the Debian packages. Is there a way to make LD_LIBRARY_PATH or similar hold for the dynamically loaded cairo.so? Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science - This SF
Re: [Plplot-devel] xcairo segmentation fault
> >> Curiously I found that if I ran my test program in the directory that > >> I had make install plplot from then I didn't see the problem. I have > >> the following the layout: > >> /home/hbabcock/C/plplot_test/test1 - the test program. > >> /home/hbabcock/OpenSource/plplot-working/plplot-CBS-1 - the directory > >> I make installed plplot from. > >> > >> This works: > >> debian ~/OpenSource/plplot-working/plplot-CBS-1 : pwd > >> /home/hbabcock/OpenSource/plplot-working/plplot-CBS-1 > >> debian ~/OpenSource/plplot-working/plplot-CBS-1 : /home/hbabcock/C/ > >> plplot_test/test1 > >> > >> This does not: > >> debian ~/C/plplot_test : pwd > >> /home/hbabcock/C/plplot_test > >> debian ~/C/plplot_test : ./test1 > >> > >> And it doesn't seem to be the absolute path since it didn't work from > >> a couple other directories that I tried. > >> Perhaps it is some sort of strange linking issue with pango / pango- > >> cairo? > > > > There isn't any chance of there being multiple copies of either pango or > > plplot on the system, does there? If so there's always a chance that > > different versions are being picked up by the dynamic linker. I can't > > imagine how that might come about (excepting the inclusion of relative > > paths in LD_LIBRARY_PATH which isn't generally a good idea) but it's a > > thought. If something like this was happening I would expect it to be > > evident through the use of ldd: > > > > cd /home/hbabcock/OpenSource/plplot-working/plplot-CBS-1 > > ldd /home/hbabcock/C/plplot_test/test1 > > > > cd /home/hbabcock/C/plplot_test > > ldd ./test1 > > > > It's a very strange problem. Is anything revealed by running test1 > > through > > strace in the two scenarios? > > ldd looks normal (at least to me): > : I agree. What about running ldd on /lib/plplot-*/cairo.so? Anything differences in this between the two working directories? The drivers are loaded dynamically on demand I think which is why the cairo libraries (for example) aren't explicitly required by the test application. > The only difference I can see in strace is that when I run in /home/ > hbabcock/OpenSource/plplot-working/plplot-CBS-1, the program looks in > this directory first before looking in /usr/lib, however all the > libraries still seem to be found in /usr/lib. Curious. Regards jonathan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xcairo segmentation fault
I forgot to CC: the list... On Wed, Mar 12, 2008 at 10:17 PM, Hazen Babcock <[EMAIL PROTECTED]> wrote: > ldd looks normal (at least to me): > debian ~/C/plplot_test : ldd test1 > linux-gate.so.1 => (0xe000) > libplplotd.so.9 => /usr/local/lib/libplplotd.so.9 (0xb7eb2000) > libc.so.6 => /lib/libc.so.6 (0xb7d65000) > libltdl.so.3 => /usr/local/lib/libltdl.so.3 (0xb7d5e000) > libdl.so.2 => /lib/libdl.so.2 (0xb7d5a000) > libm.so.6 => /lib/libm.so.6 (0xb7d34000) > libcsirocsa.so.0 => /usr/local/lib/libcsirocsa.so.0 > (0xb7d2b000) > libcsironn.so.0 => /usr/local/lib/libcsironn.so.0 (0xb7d23000) > libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7cb4000) > libqhull.so.5 => /usr/lib/libqhull.so.5 (0xb7c66000) > /lib/ld-linux.so.2 (0xb7f1a000) > libz.so.1 => /usr/lib/libz.so.1 (0xb7c51000) > > debian ~/OpenSource/plplot-working/plplot-CBS-1 : ldd /home/hbabcock/ > C/plplot_test/test1 > linux-gate.so.1 => (0xe000) > libplplotd.so.9 => /usr/local/lib/libplplotd.so.9 (0xb7f79000) > libc.so.6 => /lib/libc.so.6 (0xb7e2c000) > libltdl.so.3 => /usr/local/lib/libltdl.so.3 (0xb7e25000) > libdl.so.2 => /lib/libdl.so.2 (0xb7e21000) > libm.so.6 => /lib/libm.so.6 (0xb7dfb000) > libcsirocsa.so.0 => /usr/local/lib/libcsirocsa.so.0 > (0xb7df2000) > libcsironn.so.0 => /usr/local/lib/libcsironn.so.0 (0xb7dea000) > libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7d7b000) > libqhull.so.5 => /usr/lib/libqhull.so.5 (0xb7d2d000) > /lib/ld-linux.so.2 (0xb7fe1000) > libz.so.1 => /usr/lib/libz.so.1 (0xb7d18000) > > The only difference I can see in strace is that when I run in /home/ > hbabcock/OpenSource/plplot-working/plplot-CBS-1, the program looks in > this directory first before looking in /usr/lib, however all the > libraries still seem to be found in /usr/lib. > > Did anyone else have similar results? > > -Hazen I have the same results on Debian Sid, including no segmentation fault when running the binary (in this case an OCaml binary) from plplot-svn/build/src/, where the compiled libplplotd.so* files reside. Outside of the plplot-svn directory (segfault when I run plot.native from here): ~/Projects/ocaml/tmp$ ldd plot.native linux-gate.so.1 => (0xb7f0e000) libplplotd.so.9 => ~/Applications/plplot/lib/libplplotd.so.9 (0xb7eb7000) libltdl.so.3 => /usr/lib/libltdl.so.3 (0xb7ea) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7e9b000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7e75000) libcsirocsa.so.0 => ~/Applications/plplot/lib/libcsirocsa.so.0 (0xb7e6d000) libcsironn.so.0 => ~/Applications/plplot/lib/libcsironn.so.0 (0xb7e65000) libqhull.so.5 => /usr/lib/libqhull.so.5 (0xb7e17000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7da7000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7c4c000) /lib/ld-linux.so.2 (0xb7f0f000) libz.so.1 => /usr/lib/libz.so.1 (0xb7c37000) In the plplot-svn build directory (no segfault when I run plot.native from here): ~/tmp/BUILD/plplot/plplot-svn/build/src$ ldd ~/Projects/ocaml/tmp/plot.native linux-gate.so.1 => (0xb7fab000) libplplotd.so.9 => ~/Applications/plplot/lib/libplplotd.so.9 (0xb7f54000) libltdl.so.3 => /usr/lib/libltdl.so.3 (0xb7f3d000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7f38000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7f12000) libcsirocsa.so.0 => ~/Applications/plplot/lib/libcsirocsa.so.0 (0xb7f0a000) libcsironn.so.0 => ~/Applications/plplot/lib/libcsironn.so.0 (0xb7f02000) libqhull.so.5 => /usr/lib/libqhull.so.5 (0xb7eb4000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7e44000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7ce9000) /lib/ld-linux.so.2 (0xb7fac000) libz.so.1 => /usr/lib/libz.so.1 (0xb7cd4000) Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xcairo segmentation fault
On Mar 11, 2008, at 10:51 PM, Jonathan Woithe wrote: >> The problem seems to start in the proc_str() function at: >> layout = pango_cairo_create_layout(aStream->cairoContext); >> though it makes through several more lines of code before going down >> for good. >> >> Curiously I found that if I ran my test program in the directory that >> I had make install plplot from then I didn't see the problem. I have >> the following the layout: >> /home/hbabcock/C/plplot_test/test1 - the test program. >> /home/hbabcock/OpenSource/plplot-working/plplot-CBS-1 - the directory >> I make installed plplot from. >> >> This works: >> debian ~/OpenSource/plplot-working/plplot-CBS-1 : pwd >> /home/hbabcock/OpenSource/plplot-working/plplot-CBS-1 >> debian ~/OpenSource/plplot-working/plplot-CBS-1 : /home/hbabcock/C/ >> plplot_test/test1 >> >> This does not: >> debian ~/C/plplot_test : pwd >> /home/hbabcock/C/plplot_test >> debian ~/C/plplot_test : ./test1 >> >> And it doesn't seem to be the absolute path since it didn't work from >> a couple other directories that I tried. >> Perhaps it is some sort of strange linking issue with pango / pango- >> cairo? > > There isn't any chance of there being multiple copies of either > pango or > plplot on the system, does there? If so there's always a chance that > different versions are being picked up by the dynamic linker. I can't > imagine how that might come about (excepting the inclusion of > relative paths > in LD_LIBRARY_PATH which isn't generally a good idea) but it's a > thought. > If something like this was happening I would expect it to be > evident through > the use of ldd: > > cd /home/hbabcock/OpenSource/plplot-working/plplot-CBS-1 > ldd /home/hbabcock/C/plplot_test/test1 > > cd /home/hbabcock/C/plplot_test > ldd ./test1 > > It's a very strange problem. Is anything revealed by running test1 > through > strace in the two scenarios? ldd looks normal (at least to me): debian ~/C/plplot_test : ldd test1 linux-gate.so.1 => (0xe000) libplplotd.so.9 => /usr/local/lib/libplplotd.so.9 (0xb7eb2000) libc.so.6 => /lib/libc.so.6 (0xb7d65000) libltdl.so.3 => /usr/local/lib/libltdl.so.3 (0xb7d5e000) libdl.so.2 => /lib/libdl.so.2 (0xb7d5a000) libm.so.6 => /lib/libm.so.6 (0xb7d34000) libcsirocsa.so.0 => /usr/local/lib/libcsirocsa.so.0 (0xb7d2b000) libcsironn.so.0 => /usr/local/lib/libcsironn.so.0 (0xb7d23000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7cb4000) libqhull.so.5 => /usr/lib/libqhull.so.5 (0xb7c66000) /lib/ld-linux.so.2 (0xb7f1a000) libz.so.1 => /usr/lib/libz.so.1 (0xb7c51000) debian ~/OpenSource/plplot-working/plplot-CBS-1 : ldd /home/hbabcock/ C/plplot_test/test1 linux-gate.so.1 => (0xe000) libplplotd.so.9 => /usr/local/lib/libplplotd.so.9 (0xb7f79000) libc.so.6 => /lib/libc.so.6 (0xb7e2c000) libltdl.so.3 => /usr/local/lib/libltdl.so.3 (0xb7e25000) libdl.so.2 => /lib/libdl.so.2 (0xb7e21000) libm.so.6 => /lib/libm.so.6 (0xb7dfb000) libcsirocsa.so.0 => /usr/local/lib/libcsirocsa.so.0 (0xb7df2000) libcsironn.so.0 => /usr/local/lib/libcsironn.so.0 (0xb7dea000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7d7b000) libqhull.so.5 => /usr/lib/libqhull.so.5 (0xb7d2d000) /lib/ld-linux.so.2 (0xb7fe1000) libz.so.1 => /usr/lib/libz.so.1 (0xb7d18000) The only difference I can see in strace is that when I run in /home/ hbabcock/OpenSource/plplot-working/plplot-CBS-1, the program looks in this directory first before looking in /usr/lib, however all the libraries still seem to be found in /usr/lib. Did anyone else have similar results? -Hazen - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xcairo segmentation fault
> The problem seems to start in the proc_str() function at: > layout = pango_cairo_create_layout(aStream->cairoContext); > though it makes through several more lines of code before going down > for good. > > Curiously I found that if I ran my test program in the directory that > I had make install plplot from then I didn't see the problem. I have > the following the layout: > /home/hbabcock/C/plplot_test/test1 - the test program. > /home/hbabcock/OpenSource/plplot-working/plplot-CBS-1 - the directory > I make installed plplot from. > > This works: > debian ~/OpenSource/plplot-working/plplot-CBS-1 : pwd > /home/hbabcock/OpenSource/plplot-working/plplot-CBS-1 > debian ~/OpenSource/plplot-working/plplot-CBS-1 : /home/hbabcock/C/ > plplot_test/test1 > > This does not: > debian ~/C/plplot_test : pwd > /home/hbabcock/C/plplot_test > debian ~/C/plplot_test : ./test1 > > And it doesn't seem to be the absolute path since it didn't work from > a couple other directories that I tried. > Perhaps it is some sort of strange linking issue with pango / pango- > cairo? There isn't any chance of there being multiple copies of either pango or plplot on the system, does there? If so there's always a chance that different versions are being picked up by the dynamic linker. I can't imagine how that might come about (excepting the inclusion of relative paths in LD_LIBRARY_PATH which isn't generally a good idea) but it's a thought. If something like this was happening I would expect it to be evident through the use of ldd: cd /home/hbabcock/OpenSource/plplot-working/plplot-CBS-1 ldd /home/hbabcock/C/plplot_test/test1 cd /home/hbabcock/C/plplot_test ldd ./test1 It's a very strange problem. Is anything revealed by running test1 through strace in the two scenarios? Regards jonathan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xcairo segmentation fault
On Mar 11, 2008, at 10:17 PM, Hazen Babcock wrote: > > I'm not seeing this on OS-X, but I am seeing it on my linux box so > perhaps something changed between versions of the cairo library? > > PPC/64, pango 1.15.5, cairo 1.2.6. Ok. > > Intel/32, pango 1.16.5, cairo 1.4.10. Not Ok. The problem seems to start in the proc_str() function at: layout = pango_cairo_create_layout(aStream->cairoContext); though it makes through several more lines of code before going down for good. Curiously I found that if I ran my test program in the directory that I had make install plplot from then I didn't see the problem. I have the following the layout: /home/hbabcock/C/plplot_test/test1 - the test program. /home/hbabcock/OpenSource/plplot-working/plplot-CBS-1 - the directory I make installed plplot from. This works: debian ~/OpenSource/plplot-working/plplot-CBS-1 : pwd /home/hbabcock/OpenSource/plplot-working/plplot-CBS-1 debian ~/OpenSource/plplot-working/plplot-CBS-1 : /home/hbabcock/C/ plplot_test/test1 This does not: debian ~/C/plplot_test : pwd /home/hbabcock/C/plplot_test debian ~/C/plplot_test : ./test1 And it doesn't seem to be the absolute path since it didn't work from a couple other directories that I tried. Perhaps it is some sort of strange linking issue with pango / pango- cairo? -Hazen - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xcairo segmentation fault
On Mar 11, 2008, at 2:10 AM, Alan W. Irwin wrote:
> On 2008-03-11 00:01-0400 Hezekiah M. Carty wrote:
> Thanks for spotting this issue which I have just confirmed with the
> pscairo
> device using a freshly compiled svn version of PLplot on Debian
> testing. I
> used the following test C code:
>
>
> #include "plcdemos.h"
> int
> main(int argc, const char *argv[])
> {
>
> plinit();
> plenv(0.0, 1.0, 0.0, 1.0, 1, 0);
> plend();
> plinit();
> plenv(0.0, 1.0, 0.0, 1.0, 1, 0);
> plend();
> exit(0);
> }
>
> I built this test code identically to how the installed C examples are
> built.
>
> The first file has the expected labelled box, the second file is
> empty.
>
> Hazen, do you confirm the pscairo segfault with the above code
> on Mac OS X as well?
I'm not seeing this on OS-X, but I am seeing it on my linux box so
perhaps something changed between versions of the cairo library?
PPC/64, pango 1.15.5, cairo 1.2.6. Ok.
Intel/32, pango 1.16.5, cairo 1.4.10. Not Ok.
-Hazen
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xcairo segmentation fault
On 2008-03-10 23:10-0700 Alan W. Irwin wrote: > If the cairo device drivers does not properly shut down libcairo at plend > you could get memory management problems with symptoms like what we are > seeing. I suggest you look carefully at what the working psttf.c device > driver does in this regard since it involves a large stack of external > libraries (many of them common with the stack of libraries that cairo.c > depends on including libpangocairo and libcairo). Hi Hez, Just to clarify, the above comment was directed at Hazen, but if you want to also have a go at comparing cairo.c and psttf.cc to find the bug, that would be fine. As the other core developers know, I am in the peculiar position of having a good overview of PLplot through its build system and python interface, but I am not really that comfortable with C or C++. Thus, for core C library or device driver bugs such as you have found my role is mostly restricted to testing and confirming such issues while cheering on others to actually fix them. 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/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xcairo segmentation fault
On 2008-03-11 00:01-0400 Hezekiah M. Carty wrote:
> I think I have found a consistent segmentation fault while using the
> xcairo and pngcairo plotting devices under PLplot 5.9.0 (Debian
> packages) and svn head on Debian Sid, x86-32. I have not tested the
> other *cairo devices, but given the error messages I think it would
> affect others as well.
>
> The following sequence of commands give the segfault:
>
> plinit (selecting xcairo as the plotting device)
> plenv 0.0 1.0 0.0 1.0 1 0 (I don't think the numbers matter)
> plend
> plinit (select xcairo again)
> plenv 0.0 1.0 0.0 1.0 1 0 (Again, the numbers don't seem to matter)
> ^^ This causes a segmentation fault
Hi Hez:
Thanks for spotting this issue which I have just confirmed with the pscairo
device using a freshly compiled svn version of PLplot on Debian testing. I
used the following test C code:
#include "plcdemos.h"
int
main(int argc, const char *argv[])
{
plinit();
plenv(0.0, 1.0, 0.0, 1.0, 1, 0);
plend();
plinit();
plenv(0.0, 1.0, 0.0, 1.0, 1, 0);
plend();
exit(0);
}
I built this test code identically to how the installed C examples are
built.
The first file has the expected labelled box, the second file is empty.
Hazen, do you confirm the pscairo segfault with the above code
on Mac OS X as well?
If I specify the ps device both times instead of pscairo, I get no segfault
and two identical plots with the expected labelled box. I get similar good
results for -dev png and -dev psttf as well. So I think the problem is
specific to the cairo device driver.
If the cairo device drivers does not properly shut down libcairo at plend
you could get memory management problems with symptoms like what we are
seeing. I suggest you look carefully at what the working psttf.c device
driver does in this regard since it involves a large stack of external
libraries (many of them common with the stack of libraries that cairo.c
depends on including libpangocairo and libcairo).
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/vse012070mrt/direct/01/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xcairo segmentation fault
On Tue, Mar 11, 2008 at 12:01 AM, Hezekiah M. Carty <[EMAIL PROTECTED]> wrote: > I think I have found a consistent segmentation fault while using the > xcairo and pngcairo plotting devices under PLplot 5.9.0 (Debian > packages) and svn head on Debian Sid, x86-32. I have not tested the > other *cairo devices, but given the error messages I think it would > affect others as well. As a brief follow-up, here is the output from running these commands in octave under valgrind along with some context lines to match with my previous email. I hope this helps. Hez - (process:4091): Pango-CRITICAL **: pango_cairo_context_set_font_options: assertion `PANGO_IS_CONTEXT (context)' failed ==4091== ==4091== Invalid read of size 4 ==4091==at 0xB77742B: (within /usr/lib/libpango-1.0.so.0.1800.4) ==4091==by 0xB7774B0: pango_layout_context_changed (in /usr/lib/libpango-1.0.so.0.1800.4) ==4091==by 0x80134D1: (within /usr/lib/plplot5.9.0/driversd/cairo.so) ==4091==by 0x80146FB: plD_esc_xcairo (in /usr/lib/plplot5.9.0/driversd/cairo.so) ==4091==by 0xB65DFEC: plP_esc (in /usr/lib/libplplotd.so.9.5.0) ==4091==by 0xB65F0A3: plP_text (in /usr/lib/libplplotd.so.9.5.0) ==4091==by 0xB682212: c_plmtex (in /usr/lib/libplplotd.so.9.5.0) ==4091==by 0xB65A55B: (within /usr/lib/libplplotd.so.9.5.0) ==4091==by 0xB6569E6: c_plaxes (in /usr/lib/libplplotd.so.9.5.0) ==4091==by 0xB6549E3: c_plbox (in /usr/lib/libplplotd.so.9.5.0) ==4091==by 0xB6869B1: (within /usr/lib/libplplotd.so.9.5.0) ==4091==by 0xB686333: c_plenv (in /usr/lib/libplplotd.so.9.5.0) ==4091== Address 0x64 is not stack'd, malloc'd or (recently) free'd panic: Segmentation fault -- stopping myself... attempting to save variables to `octave-core'... save to `octave-core' complete - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
