C to Fortran weirdness - pgmtext cases a crash in the tests #14
Description
I was investigating two of the module tests that sometimes crash as noted in the code comments (v2.28):
% grep -i -A1 -B2 blows t/*.t
t/t10.t- PGPLOT::pgbox("BCST",0,0,"BCST",0,0);
t/t10.t- if ($^O ne 'freebsd') {
t/t10.t: # blows up for some reason
t/t10.t- PGPLOT::pgmtext('T',1.0,0.2,0,$_[0]);
--
t/t2.t-PGPLOT::pgarro(20,0,25,2);
t/t2.t-
t/t2.t:PGPLOT::pgmtext('B', -2.0, 0.95, 1, "This is a test") if $^O ne 'freebsd'; # blows up for some reason
t/t2.t-
Because this blows up for me too on certain MacOS configurations.
I have now determined it is NOT a perl5-PGPLOT issue at all. I can reproduce the behaviour by putting a call in pure C code to cpgmtxt() - see attached code. pgmtext() in perl calls cpgmtxt(_) which calls pgmtxt() in Fortran. For some reason this particular routine sometimes crashes when doing that.
I investigated all the underlying C and Fortran code and everything seems to be defined correctly. It seems to be general C to Fortran calling weirdness with strings unfortunately.
e.g. I found this would always crash with a segmentation violation when using macOS Monterey 12.7.2, Intel CPU, Apple cc v14.0.0 and gfortran 12.1.0.
Building all the cpgplot stuff with gcc 12.1.0 instead eliminates the crash - presumably because the Apple cc compiler can randomly deviate from the normal C->Fortran calling conventions and gcc is more consistent with gfortran. To be completely consistent it seems one must build all of perl and it's modules with gcc! (I found this eliminated random crashes in pgplot, but is obviously undesirable more generally)
Sigh...
Hopefully later MacOS versions are better at this...
There is no obvious solution to this, I just wanted to note it online somewhere accessible to google search results.