C to Fortran weirdness - pgmtext cases a crash in the tests

[karlglazebrook]

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.

cpg_crasher.c.txt

[karlglazebrook]

I boiled down the issue to a small self contained set of C and Fortran codes which demonstrate the bug. It is definitely triggered by the passing of strings in some situations.

See attachment

Compile:

cc -Wall -O -c -I. crash.c cpgmtxt.c 
gfortran -c -fPIC -O -Wno-globals pgmtxt.f grtrim.f
gfortran -fno-backslash -o crash crash.o grtrim.o pgmtxt.o cpgmtxt.o

Running ./crash will cause a crash. Switching to gcc makes it go away.

Versions:

% cc -v
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

% gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin21/12.1.0/lto-wrapper
Target: x86_64-apple-darwin21
Configured with: ../gcc-12-branch/configure --prefix=/usr/local/gfortran --build=x86_64-apple-darwin21 --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk --enable-languages=c,ada,c++,fortran,jit,lto,objc,obj-c++ --with-gmp=/Users/fx/build_package/deps --with-zstd=/Users/fx/build_package/deps --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (GCC) 

% uname -a
Darwin Dummys-MacBook-Pro.local 21.6.0 Darwin Kernel Version 21.6.0: Thu Nov  9 00:38:19 PST 2023; root:xnu-8020.240.18.705.10~1/RELEASE_X86_64 x86_64

crash_demo.tar.gz

Maybe this goes away on more recent versions?