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=100url=/ ___ 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=100url=/ ___ 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=100url=/ ___ 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 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 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 prefix/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/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net
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 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
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 Wed, Mar 12, 2008 at 11:12 PM, Jonathan Woithe [EMAIL PROTECTED] wrote: I agree. What about running ldd on prefix/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.net email is sponsored by: Microsoft Defy all challenges.
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 prefix/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 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 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
