Perl_hv_store is not defined on unthreaded perls

[mauke]

Description

Perl_hv_store is documented as API, but the only definition in core is in long_names.c, which is only available with threads. (All of long_names.c is under #ifdef USE_THREADS.) So if you try to use Perl_hv_store from XS/C and your perl was built without thread support, it breaks.

See e.g. the net-dialup/freeradius package in Gentoo, which is affected: https://bugs.gentoo.org/978687

Steps to Reproduce

I don't know how portable this is, but after make on Linux, libperl.a should exist and provide a Perl_hv_store symbol:

$ nm libperl.a | grep Perl_hv_store
$

Expected behavior

$ nm libperl.a | grep Perl_hv_store
0000000000000800 T Perl_hv_store

Perl_hv_store should be a real symbol on all configurations. (I don't understand why it is conditional on USE_THREADS.)

Perl configuration

Summary of my perl5 (revision 5 version 44 subversion 0) configuration:
  Derived from: 57f455aec1f783039270f4058af5c93ca22c431e
  Platform:
    osname=linux
    osvers=6.17.0-122035-tuxedo
    archname=x86_64-linux
    uname='linux luum 6.17.0-122035-tuxedo #35~24.04.1tux1 smp preempt_dynamic mon jun 15 14:27:53 utc 2026 x86_64 x86_64 x86_64 gnulinux '
    config_args='-Dcc=c-gcc -Dman1dir=none -Dman3dir=none -Duseshrplib -des -Dusedevel'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=undef
    usemultiplicity=undef
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
  Compiler:
    cc='c-gcc'
    ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
    optimize='-O2'
    cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
    ccversion=''
    gccversion='13.3.0'
    gccosandvers=''
    intsize=4
    longsize=8
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=16
    longdblkind=3
    ivtype='long'
    ivsize=8
    nvtype='double'
    nvsize=8
    Off_t='off_t'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='c-gcc'
    ldflags =' -fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib/x86_64-linux-gnu /usr/lib /usr/lib64
    libs=-lpthread -ldb -ldl -lm -lcrypt -lutil -lc
    perllibs=-lpthread -ldl -lm -lcrypt -lutil -lc
    libc=/lib/x86_64-linux-gnu/libc.so.6
    so=so
    useshrplib=true
    libperl=libperl.so
    gnulibc_version='2.39'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs
    dlext=so
    d_dlsymun=undef
    ccdlflags='-Wl,-E -Wl,-rpath,/usr/local/lib/perl5/5.44.0/x86_64-linux/CORE'
    cccdlflags='-fPIC'
    lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector-strong'


Characteristics of this binary (from libperl): 
  Compile-time options:
    HAS_LONG_DOUBLE
    HAS_STRTOLD
    HAS_TIMES
    PERLIO_LAYERS
    PERL_COPY_ON_WRITE
    PERL_HASH_FUNC_SIPHASH13
    PERL_HASH_USE_SBOX32
    PERL_MALLOC_WRAP
    PERL_OP_PARENT
    PERL_PRESERVE_IVUV
    PERL_USE_DEVEL
    PERL_USE_SAFE_PUTENV
    USE_64_BIT_ALL
    USE_64_BIT_INT
    USE_LARGE_FILES
    USE_LOCALE
    USE_LOCALE_COLLATE
    USE_LOCALE_CTYPE
    USE_LOCALE_NUMERIC
    USE_LOCALE_TIME
    USE_PERLIO
    USE_PERL_ATOF
  Locally applied patches:
    RC1
    uncommitted-changes
  Built under linux
  Compiled at Jul  5 2026 13:13:48
  %ENV:
    PERLBREW_BASHRC_VERSION="0.74"
    PERLBREW_HOME="/home/mauke/.perlbrew"
    PERLBREW_MANPATH="/home/mauke/perl5/perlbrew/perls/perl-5.42.2/man"
    PERLBREW_PATH="/home/mauke/perl5/perlbrew/bin:/home/mauke/perl5/perlbrew/perls/perl-5.42.2/bin"
    PERLBREW_PERL="perl-5.42.2"
    PERLBREW_ROOT="/home/mauke/perl5/perlbrew"
    PERLBREW_VERSION="0.98"
    PERLDOC="-oman"
    PERL_UNICODE="SAL"
  @INC:
    lib
    /usr/local/lib/perl5/site_perl/5.44.0/x86_64-linux
    /usr/local/lib/perl5/site_perl/5.44.0
    /usr/local/lib/perl5/5.44.0/x86_64-linux
    /usr/local/lib/perl5/5.44.0

[mauke]

My PR doesn't actually fix the issue.

[khwilliamson]

Is the PR good enough for 5.44.0?

[Leont]

My PR doesn't actually fix the issue.

Because it's only defined in libperl.a and not perl itself?

[jplesnik]

Is it blocker for 5.44.0?

[Leont]

Is it blocker for 5.44.0?

That was the big question of yesterday, but we concluded it wasn't so I'm about to release an RC2

[thesamesam]

Yes, to say it here: freeradius works fine on blead with that PR.

[bulk88]

TLDR: My conclusion is this is a severe (insta-SEGV/ILL/BUS) bug in autoconf/M4/bash/awk sandwich of https://github.com/FreeRADIUS/freeradius-server/ where an no-ithreads .so disk file is being mmaped into the address space of a process with a mmapped ithreaded libperl.so disk file.

There is nothing to fix on the .c/.h/.xs/.pm/.pl src code level from the P5P viewpoint.

This is another case of (%s: loadable library and perl binaries are mismatched (got %s handshake key %p, needed %p))
https://perldoc.perl.org/perldiag#%25s:-loadable-library-and-perl-binaries-are-mismatched-(got-%25s-handshake-key-%25p,-needed-%25p) also known as https://perldoc.perl.org/perldiag#Perl-API-version-%25s-of-%25s-does-not-match-%25sXS

BUT WITH A TWIST! that this particular case in the opposite direction and therefore this particular case is 100% SILENT. The Perl_xs_handshake() feature only works in 1 direction which is DynaLoader::.pm->.so/.dll disk file.

This fix for https://bugs.gentoo.org/978687 requires fixing the M4 code in net-dialup/freeradius until the M4 interp's gcc cmd line arg string is byte for byte identical to EU::MM's gcc cmd line arg string.

No shortcuts, no exceptions. M4's gcc cmd line string must be a 99% or 100% memcmp() match to whatever EU::MM's gcc cmd line string for that particular end user's local system.

Long story:

First let us define what a linker symbol is.

A linker symbol is a null terminated ASCII string that may be passed to https://linux.die.net/man/3/dlsym or https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getprocaddress and both commands will always spit out a non-NULL function pointer in return.

Additionally all linker symbols through their null terminated ASCII string names must automatically show up *[1] in Fortran ( https://en.wikipedia.org/wiki/GNU_Fortran ) and whatever is called "Pascal", regardless of their original src code lang. This includes C.

*[1] Free Drill included. Screws not included. Correct .o and .a files required.

The ASCII string/\w+ must meet all 3 properties in a unit test to a linker symbol.

TLDR If you can't reach it with dlsym() or GetProcAddress(), its not a linker symbol. The right word (or my word) for that /\s?\w+\s?/ is grammar token. I'm not using the Comp Sci term "identifier" because of a reason.

AFAIK it has been a P5P policy since 5.10.0 or 5.12.0 that there is no 3rd party ABI/machine code/.o/.a file level compatibility between different build configs compiled from the same 5.Even.0 P5P tarball. I'm skipping the topic of different 5.X.0 P5P tarballs,

hv_store() is supposed to be, and AFA i'm concerned, it has always been a very tiny CPP macro that wraps Perl_hv_common the linker symbol which the non-public API "front end" of the HV* API .

#define hv_store(hv, key, klen, val, hash)				\
    ((SV**) hv_common_key_len((hv), (key), (klen),			\
                              (HV_FETCH_ISSTORE|HV_FETCH_JUST_SV),	\
                              (val), (hash)))

Technically speaking, on Win32 hv_common_key_len is a CPP macro or a STDERR warning plus your choice of Syntax Error or Link Error.

In real life hv_common_key_len CPP #include expands to string Perl_hv_common_key_len.

On Win32/Win64 the ASCII stringPerl_hv_common_key_len is a Linker error (declared symbol not found) but not a Syntax error.

The only exception to this Linker Error is inside of perl5xx.dll the disk file.

On Win32, from the viewpoint of 3rd party CPAN/DARKPAN XS authors, they are invoking a secret function ptr (32b/64b) named __imp_Perl_hv_common_key_len or on newer interps __imp_Perl__hv_common in their own .dll file.

Therefore between a random XS shared lib and libperl.dll, the strict technical or strictest engineering boundary between ASCII grammar token hv_store and libperl.dll the disk file, is through the function pointer stored in static var void *__imp_Perl_hv_common_key_len ;.

Since P5P/Perl 5 does not offer .o or .a or .so/.dll mix-n-match junior-vs-retro-vs-paleolithic disk file compatibility, and instead only offers .c/.xs src code compatibility with a cavet of must #include "perl.h" first regardless of whether the end user consents or doesn't consent to typing #include "perl.h" in their .xs file.

It is not the end users choice between

typedef U32 (*PFN_SvIOK_T) (pTHX_ SV* sv);
typedef void (*PFN_Perl_croak_nocontext_T)(const char * msg, ...);

static PFN_SvIOK_T SvIOK = NULL;
static PFN_Perl_croak_nocontext_T Perl_croak_nocontext = NULL;

int
main(int argc, char **argv, char **env)
{
     SvIOK = (PFN_SvIOK_T) dlsym(libperl, "SvIOK");
     if (SvIOK == NULL) {
        Perl_croak_nocontext = (PFN_Perl_croak_nocontext_T)dlsym(libperl, "Perl_croak_nocontext");
        Perl_croak_nocontext("Error: perl has failed the Perl Conformance Standard 5th Edition.");
      }

into their C code or copy pasting #include "perl.h" the normal cargo culted way.

It is the undocumented private to P5P internals, on which perlapi.pod grammar tokens (\w+s) are void * vptr = (void *) \Perl_hv_common; and which perlapi.pod grammar tokens are PERL_STATIC_INLINE void * Perl_hv_common(pTHX_ HV *hv, SV *keysv, const char *key, STRLEN klen, int flags, int action, SV *val, U32 hash); and which perlapi.pod grammar tokens are # define hv_common_int(a,b,c,d,e) Perl_hv_common_int_Undefined_Behavior(aTHX_ a,b,c,d,e).

The bug in https://bugs.gentoo.org/978687 is a problem with that particular app not following P5P's embedding rules or PerlBrew vs System Perl rules.

https://github.com/FreeRADIUS/freeradius-server/blob/7e35457585e161c3ec63d1a9892002cb865ac770/src/modules/rlm_perl/configure.ac#L27

	dnl ############################################################
	dnl # Call ExtUtils::Embed to get compiler flags
	dnl ############################################################
	AC_MSG_NOTICE([Calling ExtUtils::Embed to get 'ccopts'])
	perl_cflags=$($PERL -MExtUtils::Embed -e ccopts)

Which ELF disk file will start the Perl process on the line above according to strace?

	AC_MSG_NOTICE([ExtUtil's ccopts were \"${perl_cflags}\"])

	dnl # -flto=auto causes linker errors under clang for some unknown reason
	mod_cflags=`echo $perl_cflags | sed -e '\
		s/-I[ ]*/-isystem /g;\
		s/-arch [^ ]*//g;\
		s/  / /g;\
		s/^ *//;\
		s/ *$//;\
		s/-fstack-clash-protection[[[:blank:]]]*//g; \
		s/-flto=auto//g; \
		'`

CENSORED is going on here ???

This is prime proof this 3rd party SW is doing something very illegal (or experimental/unstable) on the AMD64/ARM/i386 machine code level.

Emptying ENTIRE C compiler cmd line string of all Perl 5's/P5P's cmd line args down to the

gcc -c -Wall hello.xs
gcc -shared -o hello.so hello.o
cp ./hello.so ./blib/arch/auto/hello.so

level is user error.

s/-I[ ]*/-isystem /g;\

Poof goes access to the correct /lib/CORE/*.h files , if I'm reading this correctly.

https://978687.bugs.gentoo.org/attachment.cgi?id=966399

LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,--defsym=__gentoo_check_ldflags__=0"
LDFLAGS_amd64="-m elf_x86_64"
LDFLAGS_x32="-m elf32_x86_64"
LDFLAGS_x86="-m elf_i386"
LESS="-R -M --shift 5"
LESSOPEN="|lesspipe %s"
LEX="flex"
LIBDIR_amd64="lib64"
LIBDIR_x32="libx32"
LIBDIR_x86="lib"
LLVM_TARGETS="X86" <<<<<<<< IS THIS A X64 HOST/X64 PROCESS CREATING A i386 ELF FILE?
LUA_SINGLE_TARGET="lua5-1"
LUA_TARGETS="lua5-1"
MAILTO="tinderbox@zwiebeltoralf.de"
MAKEFLAGS="--jobserver-auth=fifo:/dev/steve"
MAKEOPTS="-O -j4"
MANPAGER="manpager"
MANPATH="/etc/java-config-2/current-system-vm/man:/usr/share/gcc-data/x86_64-pc-linux-gnu/16/man:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.46.1/man:/etc/java-config-2/current-system-vm/man/:/usr/local/share/man:/usr/share/man:/usr/lib/rust/man-bin-1.94.1:/usr/lib/rust/man-bin-1.95.0:/usr/lib/llvm/22/share/man:/usr/lib/llvm/21/share/man:/usr/lib/llvm/20/share/man:/usr/share/erlang/man"
MIX_REBAR3="/usr/bin/rebar3"
MOZ_GMP_PATH="/usr/lib64/nsbrowser/plugins/gmp-gmpopenh264/system-installed"
MULTILIB_ABIS="amd64" <<<<<<<< IS THIS A X64 HOST/X64 PROCESS CREATING A i386 ELF FILE?
MULTILIB_STRICT_DENY="64-bit.*shared object"
MULTILIB_STRICT_DIRS="/lib32 /lib /usr/lib32 /usr/lib /usr/kde/*/lib32 /usr/kde/*/lib /usr/qt/*/lib32 /usr/qt/*/lib /usr/X11R6/lib32 /usr/X11R6/lib"
MULTILIB_STRICT_EXEMPT="(perl5|gcc|binutils|eclipse-3|debug|portage|udev|systemd|clang|python-exec|llvm)" <<<<<<<<< WHAT IS THIS?
NINJAOPTS=""

Running tests for rlm_perl

checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E
checking whether perl executable path has been provided... no
checking for perl... /usr/bin/perl
configure: Calling ExtUtils::Embed to get 'ccopts'
configure: ExtUtil's ccopts were " -O2 -pipe -march=native -fno-diagnostics-color -fno-strict-aliasing -DNO_PERL_RAND_SEED -fwrapv -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -I/usr/lib64/perl5/5.44/x86_64-linux/CORE "
configure: Sanitized ccopts are "-O2 -pipe -march=native -fno-diagnostics-color -fno-strict-aliasing -DNO_PERL_RAND_SEED -fwrapv -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -isystem /usr/lib64/perl5/5.44/x86_64-linux/CORE"
configure: Calling ExtUtils::Embed to get 'ldflags'

What is no prefix string -isystem /usr/lib64/perl5/5.44/x86_64-linux/CORE" doing here? Is this correct spelling for scanning a directory for .hs on Perl on GCC on Linux? IDK enough about this niche.

Going back to

	dnl # Call ExtUtils::Embed to get compiler flags
	dnl ############################################################
	AC_MSG_NOTICE([Calling ExtUtils::Embed to get 'ccopts'])
	perl_cflags=$($PERL -MExtUtils::Embed -e ccopts)

If I run that command line on Windows. there is a 25% chance (uneducated guess)of creating a perma-SEGVing XS .dll file for WinPerl because this string -O1 -MD -Zi -DNDEBUG -GL -fp:precise -DVERSION=\"0.01\" -DXS_VERSION=\"0.01\" is missing from perl -MExtUtils::Embed -e ccopts

BAD

C:\sources\Win32-ExeAsDll>perl -MExtUtils::Embed -e ccopts
 -nologo -GF -W3 -O1 -MD -Zi -DNDEBUG -GL -fp:precise -DWIN32 -D_CONSOLE -DNO_ST
RICT -DWIN64 -DCONSERVATIVE -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECA
TE -D_WINSOCK_DEPRECATED_NO_WARNINGS -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CON
TEXT -DPERL_IMPLICIT_SYS -DWIN32_NO_REGISTRY -DUSE_PERLIO  -I"C:\p530\lib\CORE"

C:\sources\Win32-ExeAsDll>

GOOD typical EU::MM on Win64

cl -c   -nologo -GF -W3 -O1 -MD -Zi -DNDEBUG -GL -fp:precise -DWIN32 -D_CONSOLE
-DNO_STRICT -DWIN64 -DCONSERVATIVE -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_
DEPRECATE -D_WINSOCK_DEPRECATED_NO_WARNINGS -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLI
CIT_CONTEXT -DPERL_IMPLICIT_SYS -DWIN32_NO_REGISTRY -DUSE_PERLIO -O1 -MD -Zi -DN
DEBUG -GL -fp:precise   -DVERSION=\"0.01\" -DXS_VERSION=\"0.01\"  "-IC:\p530\lib
\CORE"   ExeAsDll.c

Next issue
https://github.com/FreeRADIUS/freeradius-server/blob/7e35457585e161c3ec63d1a9892002cb865ac770/src/modules/rlm_perl/configure.ac#L91

	AC_MSG_CHECKING([we can link to Perl_hv_store()])
	AC_LINK_IFELSE([AC_LANG_PROGRAM([[]], [[
		extern char Perl_hv_store(); <<<<<<<<<<<<<<<
		Perl_hv_store();
	]])],[LINKS="yes"],[LINKS="no"])

What kind of function pointer type is C src string extern char Perl_hv_store(); creating?

Remember to include ALL .o file level ELF Linux GCC/G++ name mangling rules/symbol resolution rules in your answer.

Also I would like to know if autoconf can detect Perl's

extern Signal_t void PL_op_name(int, Siginfo_t*, void*); /* <<<-- NOT A MISTAKE!!! */

function symbol on all platform?

Plus since there is nothing wrong with the below line of C code

extern Signal_t void PL_op_name(int, Siginfo_t*, void*);

can it made into a unit test and added to blead?

I know the answers for what Win32/Win64 but this ticket is about Gentoo and the behavior of the particular glibc/ld.so/gcc/g++ disk files that with it's .iso file.

[bulk88]

Nothing in this symbol probing code is correct. Its going to SEGV 100% of the time.

Calling unprototyped undeclared C functions is a required feature by ISO C law.
It is not a bug, but a specification requirement for all C compilers.
The ISO C TC couldn't care less that 100% of all usage of this C language feature is end users doing spelling mistakes..

Docs about this C feature specifically https://www.ibm.com/docs/en/xl-c-aix/13.1.0?topic=descriptions-qproto

IDK and there is no point in investigating (and IDK how to), what happens when this executes

print("ch=%u\n", (U32) ((char(*)(void))Perl_hv_store)());

Infact, after setting up a Win64 equivalent of

print("ch=%u\n", (U32) ((char(*)(void))Perl_hv_store)());

I have learned FOUR out of 5 times, that C statement DOES ... NOT ... CRASH !!! the Win64 on X64 interpreter.

I am not joking. The test code I used.

static void S_hvstoretest(pTHX_ CV* cv)
{
    dVAR;   dXSARGS;
    printf("ch=%u\n", (U32) ((char(*)(void))Perl_hv_common)());
    return;
}

So on Linux's, OSX's and AIX's ld.so implementations, do unresolvable extern linker functions symbols visibly crash at runtime or do all unresolved extern visibility C functions quietly turn into NOOPs that return value 0 and ignore all of their incoming C args?

https://github.com/FreeRADIUS/freeradius-server/blob/7e35457585e161c3ec63d1a9892002cb865ac770/src/modules/rlm_perl/configure#L4000

fail="$fail libperl.so"

	fi

	{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking we can link to Perl_hv_store()" >&5
printf %s "checking we can link to Perl_hv_store()... " >&6; }
	cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h.  */

int
main (void)
{

		extern char Perl_hv_store();
		Perl_hv_store();

  ;
  return 0;
}
_ACEOF
if ac_fn_c_try_link "$LINENO"
then :
  LINKS="yes"
else $as_nop
  LINKS="no"
fi
rm -f core conftest.err conftest.$ac_objext conftest.beam \
    conftest$ac_exeext conftest.$ac_ext

	{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: $LINKS" >&5
printf "%s\n" "$LINKS" >&6; }
	if test "x$LINKS" = "xno"; then

fail="$fail libperl.so"

	fi

	CFLAGS="$old_CFLAGS"
	LIBS="$old_LIBS"
fi


	targetname=rlm_perl
else
	targetname=
	echo \*\*\* module rlm_perl is disabled.

C:\sources>perl testinline.pl
Press any key to continue . . .
Use of uninitialized value in subroutine entry at testinline.pl line 48.
ch=0
Free to wrong pool 268950 not 14.

C:\sources>perl testinline.pl
Press any key to continue . . .
Use of uninitialized value in subroutine entry at testinline.pl line 48.
ch=0

C:\sources>perl testinline.pl
Press any key to continue . . .
Use of uninitialized value in subroutine entry at testinline.pl line 48.
ch=0

C:\sources>perl testinline.pl
Press any key to continue . . .
Use of uninitialized value in subroutine entry at testinline.pl line 48.
ch=0

C:\sources>perl testinline.pl
Press any key to continue . . .
Use of uninitialized value in subroutine entry at testinline.pl line 48.
ch=0
Free to wrong pool 318950 not 10.

demo code

BEGIN {
    #push(@INC,'./blib/arch','./blib/lib','../blib/arch','../blib/lib','.','..','./t');
    unshift(@INC,'./blib/arch','./blib/lib','../blib/arch','../blib/lib','.','..','./t');
    system 'pause' if 0;
    my $ptrsize = length(pack('P',""));
    eval 'sub PTRLET(){return \''.($ptrsize==4?'L':'Q').'\';}'
        .'sub PTRSIZE(){return '.($ptrsize==4?'4':'8').';}';
}

use strict;
use warnings;
#use Config;
use Inline C => Config => PRE_HEAD => '#define PERL_NO_GET_CONTEXT 1';
use Inline C => Config => BUILD_NOISY => 1;
use Inline C => Config => libs => '-lpsapi';
BEGIN {
    my $TTCtests = '
static void S_hvstoretest(pTHX_ CV* cv)
{
    dVAR;   dXSARGS;
    printf("ch=%u\n", (U32) ((char(*)(void))Perl_hv_common)());
    return;
}

void BOOT9() {
    dTHX;
    newXS( "hvstoretest", S_hvstoretest, __FILE__);
}
';
    Inline->bind('C' => $TTCtests);
    system('pause');
    BOOT9();
    hvstoretest();
}

Without single stepping the asm ( I could do that but its irrelavent to this bug), my guess is printf("ch=%u\n", (U32) ((char(*)(void))Perl_hv_common)()); rarely SEGVs or never SEGVs on Win64, since the address in XSUB's CV* cv arg is being inherited through uninit memory/uninit registers, and it shortly becomes Perl_hv_common()s incoming HV* hv argument.

Since no-DDEBUGGING Perl_hv_common() has zero sanity checks on its incoming HV* hv argument, passing a ptr to a 'SvTYPE() == SVt_PVCVheadinto Perl_hv_common()s HV* hv arg doesn't SEGV and doesn't "panic:".

Remember &SvPVX() == &HvARRAY() ==&CvPROTO(sv).

[bulk88]

I have no plans to start any Linux procs in relation to this ticket, but I did downloaded and installed the Ubuntu FreeRadius Perl package with apt-get. I do not know the age or version nums of whatever binaries I am looking at locally.

But the FreeRadius Perl package's C src code needs the boiler plate #define PERL_NO_GET_CONTEXT line added.

I see dozens of Perl_get_context() in each C function inside my rlm_perl.so file, which on my system, are this asm code sequence

.text:0000000000004962 48 8B 05 4F 66 00 00                mov     rax, cs:PL_thr_key_ptr
.text:0000000000004969 8B 38                               mov     edi, [rax]
.text:000000000000496B E8 40 EF FF FF                      call    pthread_getspecific_0

rlm_perl.so is also heavily using the dlopen()/dlsym() API to interact with libperl.so (which one???)

https://github.com/FreeRADIUS/freeradius-server/blob/7e35457585e161c3ec63d1a9892002cb865ac770/src/modules/rlm_perl/rlm_perl.c#L1111

	perl_dlhandle = dl_open_by_sym("perl_construct", RTLD_NOW | RTLD_GLOBAL);

IDK how safe or how dangerous FreeRadius's Linux C code is about accidentally finding the wrong libperl.so disk file to mmap into the non-perl Linux process.