Many core dumps in v5.38.0 during tests on 64-bit Solaris

[rkennedy]

Description
My team is trying to build 64-bit Perl 5.38.0 on Solaris. The build succeeds, but make test reports many failures, core dumps.

Steps to Reproduce

$ ./Configure -Dcc=/bin/cc -des -Dusethreads -Duseshrplib=false -Dnoextensions=ODBM_File -A ccflags=-m64
...
$ make
...
$ make test TEST_FILES=test_pl/can_isa_ok.t
...
./runtests choose
t/test_pl/can_isa_ok ... FAILED--non-zero wait status: 139
Failed 1 test out of 1, 0.00% okay.
        test_pl/can_isa_ok.t
...

Many tests fail, but test_pl/can_isa_ok is the first one, and it looks like the rest all fail the same way, so there's no need to run any more than that one.

Here's the compiler I'm using:

$ /bin/cc -V
cc: Studio 12.6 Sun C 5.15 SunOS_i386 2017/05/30

Here's the stack trace from the core dump:

core 't/core' of 29062: ./perl TEST test_pl/can_isa_ok.t
 00000000005937ef Perl_newSVhek () + 1f
 000000000058eb35 S_anonymise_cv_maybe () + 85
 000000000058dc30 Perl_sv_kill_backrefs () + e0
 00000000005510ad Perl_magic_killbackrefs () + d
 000000000058d587 S_sv_unmagicext_flags () + a7
 000000000058ecc8 Perl_sv_clear () + d8
 000000000058fd35 Perl_sv_free2 () + 125
 0000000000583cd2 do_clean_all () + 32
 000000000058380e S_visit () + 10e
 0000000000583cfb Perl_sv_clean_all () + 1b
 000000000046f300 perl_destruct () + 1220
 0000000000445c19 main () + 129
 0000000000445974 ???????? ()

We happen to be using Solaris on x86, but we observe the same issue on Sparc.

With git bisect, we determined that the commit where the failures began was 2e4090b. Specifically, it's this change in sv.c:

@@ -6558,7 +6558,7 @@ S_anonymise_cv_maybe(pTHX_ GV *gv, CV* cv)
     }

     /* if not, anonymise: */
-    gvname = (GvSTASH(gv) && HvNAME(GvSTASH(gv)) && HvENAME(GvSTASH(gv)))
+    gvname = (GvSTASH(gv) && HvHasNAME(GvSTASH(gv)) && HvHasENAME(GvSTASH(gv)))
                     ? newSVhek(HvENAME_HEK(GvSTASH(gv)))
                     : newSVpvn_flags( "__ANON__", 8, 0 );
     sv_catpvs(gvname, "::__ANON__");

If I revert the entire commit, or even if I revert just that one line, then all the tests pass again. Furthermore, I found that I only need to revert the HvHasENAME call back to HvENAME to make the tests pass; HvHasNAME can stay as-is.

I'm not suggesting that there's anything wrong with the commit. I don't see anything questionable about the changes in that commit. However, there definitely seems to be something wrong related to names of stashes. Unfortunately, I have zero knowledge of Perl internals, so I'm unable to continue my investigation any further.

Expected behavior
The tests should pass.

Perl configuration

Summary of my perl5 (revision 5 version 38 subversion 0) configuration:
  Commit id: 76298ae68aa7796f0ffc05095b127d23f4b2de8f
  Platform:
    osname=solaris
    osvers=2.10
    archname=i86pc-solaris-thread-multi-64
    uname='sunos devsolx8610u11vm01 5.10 generic_147148-26 i86pc i386 i86pc '
    config_args='-Dcc=/bin/cc -des -Dusethreads -Duseshrplib=false -Dnoextensions=ODBM_File -A ccflags=-m64'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=define
    usemultiplicity=define
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
  Compiler:
    cc='/bin/cc'
    ccflags ='-D_REENTRANT -m64 -xarch=generic64 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
    optimize='-O'
    cppflags='-D_REENTRANT -m64'
    ccversion='Studio 12.6 Sun C 5.15 SunOS_i386 2017/05/30'
    gccversion=''
    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='/bin/cc'
    ldflags =' -L/usr/lib -L/usr/ccs/lib -L/opt/developerstudio12.6/lib/compilers/amd64 -L/lib/64 -xarch=generic64 '
    libpth=/usr/lib /usr/ccs/lib /opt/developerstudio12.6/lib/compilers/amd64 /lib/64
    libs=-lpthread -lsocket -lnsl -ldl -lm -lc
    perllibs=-lpthread -lsocket -lnsl -ldl -lm -lc
    libc=/lib/libc.so
    so=so
    useshrplib=false
    libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs
    dlext=so
    d_dlsymun=undef
    ccdlflags=' '
    cccdlflags='-KPIC'
    lddlflags=' -G -xarch=generic64 -L/usr/lib -L/usr/ccs/lib -L/opt/developerstudio12.6/lib/compilers/amd64 -L/lib/64'


Characteristics of this binary (from libperl):
  Compile-time options:
    HAS_LONG_DOUBLE
    HAS_STRTOLD
    HAS_TIMES
    MULTIPLICITY
    PERLIO_LAYERS
    PERL_COPY_ON_WRITE
    PERL_DONT_CREATE_GVSV
    PERL_HASH_FUNC_SIPHASH13
    PERL_HASH_USE_SBOX32
    PERL_MALLOC_WRAP
    PERL_OP_PARENT
    PERL_PRESERVE_IVUV
    PERL_USE_SAFE_PUTENV
    USE_64_BIT_ALL
    USE_64_BIT_INT
    USE_ITHREADS
    USE_LARGE_FILES
    USE_LOCALE
    USE_LOCALE_COLLATE
    USE_LOCALE_CTYPE
    USE_LOCALE_NUMERIC
    USE_LOCALE_TIME
    USE_PERLIO
    USE_PERL_ATOF
    USE_REENTRANT_API
  Built under solaris
  Compiled at Sep 29 2023 09:15:38
  @INC:
    lib
    /opt/lib/perl5/site_perl/5.38.0/i86pc-solaris-thread-multi-64
    /opt/lib/perl5/site_perl/5.38.0
    /opt/lib/perl5/5.38.0/i86pc-solaris-thread-multi-64
    /opt/lib/perl5/5.38.0

[tonycoz]

If I revert the entire commit, or even if I revert just that one line, then all the tests pass again. Furthermore, I found that I only need to revert the HvHasENAME call back to HvENAME to make the tests pass; HvHasNAME can stay as-is.

That seems strange, HvENAME() is HvENAME_get(hv) and HvENAME_get(hv) is (HvHasENAME(hv) ? HEK_KEY(HvENAME_HEK_NN(hv)) : NULL) so the HvHasENAME() is being called whether or not you revert HvHasENAME to HvENAME.

That said I managed to reproduce this with Oracle Developer Studio on Oracle Linux, though I'll want a faster VM before I try resolving this further.

[tonycoz]

From what I can tell this is a compiler bug.

If I change HvENAME_HEK_NN() into a static function it fixes the problem.

If I change the optimization level to -xO1 it fixes the problem.

Do the tests pass for you if you Configure with -Doptimize=-xO1 ?

[thoke]

I can confirm that using -Doptimize=-x01 seems to resolve the issue.