NULL shown as `NaN` on riscv64

[df7cb]

On the upcoming riscv64 architecture, one of the plr regression tests fails:

333s --- /tmp/autopkgtest-lxc.7bqf0u4m/downtmp/build.3wN/src/expected/out_args.out  2024-08-04 17:40:44.000000000 +0000
333s +++ /tmp/autopkgtest-lxc.7bqf0u4m/downtmp/build.3wN/src/results/out_args.out   2024-09-16 22:30:19.008266774 +0000
333s @@ -29,7 +29,7 @@
333s    x   |  y  
333s  ------+-----
333s    123 | 246
333s -      |    
333s +      | NaN
333s   42.5 |  85
333s  (3 rows)

https://ci.debian.net/packages/p/plr/testing/riscv64/51768178/

(This is on PG17, but since the architecture is new, I can't say if it worked on the older majors.)

[davecramer]

Any chance you can debug it or provide us access to a machine ?

[df7cb]

Sorry it's kind of hard to get there. I haven't even managed to get the test suite running at build-time, i.e. at the moment it wants the package installed to the final location before make installcheck works (Debian packages install stuff to debian/tmp/$prefix, run the tests there, and then wrap the package). But looking at the Debian package git log, the problem back then looks like the same location that is failing now:

    Testing at build time does not work yet:

    Error in dyn.load("$6c69626469722f706c72") :
      unable to load shared object '/home/cbe/tmp/pg_virtualenv.aDRANl/data/13/regress/$6c69626469722f706c72':
      /home/cbe/tmp/pg_virtualenv.aDRANl/data/13/regress/$6c69626469722f706c72: cannot open shared object file: No such file or directory
    2020-10-06 16:10:25.670 CEST [854941] cbe@contrib_regression ERROR:  R interpreter expression evaluation error
    2020-10-06 16:10:25.670 CEST [854941] cbe@contrib_regression DETAIL:  R expression evaluation error caught in "dyn.load("\x246c69626469722f706c72")".
    2020-10-06 16:10:25.670 CEST [854941] cbe@contrib_regression STATEMENT:  select * from out__float8(ARRAY[123,NULL,42.5]);

I'll try poking around with it a bit more, but from reading the code a bit earlier this morning, it looks like a problem that might be anywhere and being unfamiliar with the code doesn't help.

[davecramer]

Error in dyn.load("$6c69626469722f706c72") : looks like the root of the problem.

Thanks!