In the current PDL git (essentially 2.4.7) t/plplot.t fails on my Mac (10.6.4). Apparently it only fails on OS X, not on other OSs (Puneet Kishor reported this some time ago (see http://mailman.jach.hawaii.edu/pipermail/perldl/2010-August/004361.html and http://mailman.jach.hawaii.edu/pipermail/perldl/2010-September/004474.html\). I have traced the problem all the way back to c_plshades() in the ppdef('plshades') call in plplot.pd (around line 3134).
It does not seem to be a problem with the underlying plplot library, since example x16c (which demonstrates plshades) works just fine. For reference, my plplot is 5.9.6, installed using MacPorts (though I believe Puneet installed from source manually and also has the same problem). Assigning to Doug Hunt for now unless someone else volunteers. perldl -V output attached.
output of "perldl -V"
I recommend putting an example reproducing the error in-line
to this ticket for easy reference.
sure, here goes. In PDL source directory, do:
$ perl -Mblib t/plplot.t
1..35
ok 1 - use PDL::Graphics::PLplot;
<---snip--->
ok 16 - plgvpd call works correctly
ok 17 - plgvpw call works correctly
DAL: trying plshades (within plplot.t)
DAL:trying c_plshades (within plplot.pd)
Segmentation fault
those two DAL lines are print statments I put in, obviously. The c_plshades statement is right before the c_plshades call in ppdef('plshades') in plplot.pd.
Derek-
Do you get any additional information if you compile PDL and plplot
with -g and either run the code under gdb or use gdb to look at the
trackback from the segfault? The recent BSD problem motivating the
2.4.9 release was tracked down to the problem line almost immediately
that way....at least after I remembered how to use gdb with core dumps...
--Chris
Do you still see the problem with the PDL-2.4.8_004.tar.gz? Maybe
the other bugs that were fixed are related.
Yes, still present in current git. (2.4.9_001). I have compiled the PLplot 5.9.7 with debugging ('-g') and also passed '-g' to the OPTIMIZE key in perldl.conf. Moving t/plplot.t to the current directory (so that I could add a 'use blib;' to it, and commenting out test 2 (a crash test), I get the following output (attached). From a backtrace it seems that the plshades call gets out of PDL-land and several subroutines into PLplot-land, whereupon the kernel throws an EXC_BAD_ACCESS (Could not access memory) error.
I'm not sure where to go from here, though.
output of gdb session showing stack backtrace
as a potentially-interesting aside, I did get essentially the same failure (without debugging info) INTERMITTENTLY on a 64-bit Linux server. What was unusual there is that 'perl -Mblib t/plplot.t' would fail maybe once every 5 or 6 times it was run, at the same point that I'm seeing the failure on OS X. The machine has an old Linux (FC4 I think?) and Perl 5.8.8, and I'm not even sure how new the PLplot is, so that's probably not the best debugging base. But maybe it gives somebody an idea.
Is it possible to reproduce the problem with a smaller
amount of perl code? Say 1 or 2 tests rather than
all 35? It may make things easier to isolate. Looking
at the gdb output I can't tell which test had the failure.
Another idea would be to put some diagnostic print
statements in the PLplot.xs file (say around line 25000
or 39893....
Bug fixed in Git.
Thanks for reporting the problem!
This seems to work now, I get no segfault when running either the PLplot perl example 16, or the PDL::Graphics::PLplot test suite. Thanks!