ext/XS-APItest/t/locale.t crashes on Windows after passing a couple tests

[p5pRT]

Migrated from rt.perl.org#133981 (status was 'pending release')

Searchable as RT133981$

[p5pRT]

From @steve-m-hay

Created by @steve-m-hay

Blead is currently crashing at the end of ext/XS-APItest/t/locale.t on
Windows (this is Windows 10).

I get the same result using VC14 and VC14.1, but VC12 and MinGW-w64
GCC 7.1.0 work fine, all x64.

Verbose output​:

../ext/XS-APItest/t/locale.t ..
ok 1 - Gconvert doesn't recognize underlying locale outside 'use locale'
ok 2 - Gconvert doesn't recognize underlying locale inside 'use locale'
Dubious, test returned 9 (wstat 2304, 0x900)
All 2 subtests passed

Test Summary Report
-------------------
../ext/XS-APItest/t/locale.t (Wstat​: 2304 Tests​: 2 Failed​: 0)
  Non-zero exit status​: 9
  Parse errors​: No plan found in TAP output
Files=1, Tests=2, 3 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)
Result​: FAIL

Perl Info

Flags:
    category=core
    severity=medium

Site configuration information for perl 5.29.10:

Configured by shay at Wed Apr  3 09:30:51 2019.

Summary of my perl5 (revision 5 version 29 subversion 10) configuration:
  Commit id: 930ded6545f2602708b01c3a2fdfe43bcaf771a6
  Platform:
    osname=MSWin32
    osvers=10.0.17763.379
    archname=MSWin32-x64-multi-thread
    uname=''
    config_args='undef'
    hint=recommended
    useposix=true
    d_sigaction=undef
    useithreads=define
    usemultiplicity=define
    use64bitint=define
    use64bitall=undef
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
    bincompat5005=undef
  Compiler:
    cc='cl'
    ccflags ='-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_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS'
    optimize='-O1 -MD -Zi -DNDEBUG -GL -fp:precise'
    cppflags='-DWIN32'
    ccversion='19.16.27025.1'
    gccversion=''
    gccosandvers=''
    intsize=4
    longsize=4
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=undef
    longlongsize=8
    d_longdbl=define
    longdblsize=8
    longdblkind=0
    ivtype='__int64'
    ivsize=8
    nvtype='double'
    nvsize=8
    Off_t='__int64'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='link'
    ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -ltcg
-libpath:"c:\perl\lib\CORE"  -machine:AMD64'
    libpth="C:\Program Files (x86)\Microsoft Visual Studio\2017
15.9\Professional\VC\Tools\MSVC\14.16.27023\\lib\x64"
    libs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib
odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib vcruntime.lib ucrt.lib
    perllibs=oldnames.lib kernel32.lib user32.lib gdi32.lib
winspool.lib  comdlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib
version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib
vcruntime.lib ucrt.lib
    libc=ucrt.lib
    so=dll
    useshrplib=true
    libperl=perl529.lib
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_win32.xs
    dlext=dll
    d_dlsymun=undef
    ccdlflags=' '
    cccdlflags=' '
    lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf -ltcg
-libpath:"c:\perl\lib\CORE"  -machine:AMD64'



@INC for perl 5.29.10:
    C:/perl/site/lib
    C:/perl/lib


Environment for perl 5.29.10:
    HOME (unset)
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\perl\bin
    PERL_BADLANG (unset)
    SHELL (unset)

[p5pRT]

From @khwilliamson

On 4/3/19 11​:00 AM, Steve Hay (via RT) wrote​:

# New Ticket Created by Steve Hay
# Please include the string​: [perl #133981]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133981 >

This is a bug report for perl from steve.m.hay@​googlemail.com,
generated with the help of perlbug 1.41 running under perl 5.29.10.

-----------------------------------------------------------------
[Please describe your issue here]

Blead is currently crashing at the end of ext/XS-APItest/t/locale.t on
Windows (this is Windows 10).

I get the same result using VC14 and VC14.1, but VC12 and MinGW-w64
GCC 7.1.0 work fine, all x64.

Verbose output​:

../ext/XS-APItest/t/locale.t ..
ok 1 - Gconvert doesn't recognize underlying locale outside 'use locale'
ok 2 - Gconvert doesn't recognize underlying locale inside 'use locale'
Dubious, test returned 9 (wstat 2304, 0x900)
All 2 subtests passed

Test Summary Report
-------------------
../ext/XS-APItest/t/locale.t (Wstat​: 2304 Tests​: 2 Failed​: 0)
Non-zero exit status​: 9
Parse errors​: No plan found in TAP output
Files=1, Tests=2, 3 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)
Result​: FAIL

Since I don't have access to a box where this is failing, this will take
some back and forth effort.

Let's start by running this single test manually on a DEBUGGING build
with -DL and sending me the output.

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @steve-m-hay

(And again, with gzipped attachment, since the plain text was too large.)

On Thu, 4 Apr 2019 at 22​:09, Steve Hay <steve.m.hay@​googlemail.com> wrote​:

On Thu, 4 Apr 2019 at 21​:23, Karl Williamson <public@​khwilliamson.com> wrote​:

On 4/3/19 11​:00 AM, Steve Hay (via RT) wrote​:

# New Ticket Created by Steve Hay
# Please include the string​: [perl #133981]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133981 >

This is a bug report for perl from steve.m.hay@​googlemail.com,
generated with the help of perlbug 1.41 running under perl 5.29.10.

-----------------------------------------------------------------
[Please describe your issue here]

Blead is currently crashing at the end of ext/XS-APItest/t/locale.t on
Windows (this is Windows 10).

I get the same result using VC14 and VC14.1, but VC12 and MinGW-w64
GCC 7.1.0 work fine, all x64.

Verbose output​:

../ext/XS-APItest/t/locale.t ..
ok 1 - Gconvert doesn't recognize underlying locale outside 'use locale'
ok 2 - Gconvert doesn't recognize underlying locale inside 'use locale'
Dubious, test returned 9 (wstat 2304, 0x900)
All 2 subtests passed

Test Summary Report
-------------------
../ext/XS-APItest/t/locale.t (Wstat​: 2304 Tests​: 2 Failed​: 0)
Non-zero exit status​: 9
Parse errors​: No plan found in TAP output
Files=1, Tests=2, 3 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)
Result​: FAIL

Since I don't have access to a box where this is failing, this will take
some back and forth effort.

Let's start by running this single test manually on a DEBUGGING build
with -DL and sending me the output.

STDERR output from the following is attached, along with the
corresponding perl -V​:

D​:\Dev\Git\perl\ext\XS-APItest>..\..\perl -DL t\locale.t 2>out.txt
ok 1 - Gconvert doesn't recognize underlying locale outside 'use locale'
ok 2 - Gconvert doesn't recognize underlying locale inside 'use locale'

[p5pRT]

From @steve-m-hay

Summary of my perl5 (revision 5 version 29 subversion 10) configuration​:
  Local Commit​: 5ad9dc4e4c9af0670b9d5374504d93a5d9fd0239
  Ancestor​: 281cff2
  Platform​:
  osname=MSWin32
  osvers=10.0.17763.379
  archname=MSWin32-x64-multi-thread
  uname=''
  config_args='undef'
  hint=recommended
  useposix=true
  d_sigaction=undef
  useithreads=define
  usemultiplicity=define
  use64bitint=define
  use64bitall=undef
  uselongdouble=undef
  usemymalloc=n
  default_inc_excludes_dot=define
  bincompat5005=undef
  Compiler​:
  cc='cl'
  ccflags ='-nologo -GF -W3 -Od -MD -Zi -DDEBUGGING -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_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS'
  optimize='-Od -MD -Zi -DDEBUGGING -fp​:precise'
  cppflags='-DWIN32'
  ccversion='19.15.26730'
  gccversion=''
  gccosandvers=''
  intsize=4
  longsize=4
  ptrsize=8
  doublesize=8
  byteorder=12345678
  doublekind=3
  d_longlong=undef
  longlongsize=8
  d_longdbl=define
  longdblsize=8
  longdblkind=0
  ivtype='__int64'
  ivsize=8
  nvtype='double'
  nvsize=8
  Off_t='__int64'
  lseeksize=8
  alignbytes=8
  prototype=define
  Linker and Libraries​:
  ld='link'
  ldflags ='-nologo -nodefaultlib -debug -libpath​:"c​:\perl\lib\CORE" -machine​:AMD64 -subsystem​:console,"5.02"'
  libpth="C​:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.15.26726\\lib\x64"
  libs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib vcruntime.lib ucrt.lib
  perllibs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib vcruntime.lib ucrt.lib
  libc=ucrt.lib
  so=dll
  useshrplib=true
  libperl=perl529.lib
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_win32.xs
  dlext=dll
  d_dlsymun=undef
  ccdlflags=' '
  cccdlflags=' '
  lddlflags='-dll -nologo -nodefaultlib -debug -libpath​:"c​:\perl\lib\CORE" -machine​:AMD64 -subsystem​:console,"5.02"'

Characteristics of this binary (from libperl)​:
  Compile-time options​:
  DEBUGGING
  HAS_TIMES
  HAVE_INTERP_INTERN
  MULTIPLICITY
  PERLIO_LAYERS
  PERL_COPY_ON_WRITE
  PERL_DONT_CREATE_GVSV
  PERL_IMPLICIT_CONTEXT
  PERL_IMPLICIT_SYS
  PERL_MALLOC_WRAP
  PERL_OP_PARENT
  PERL_PRESERVE_IVUV
  PERL_TRACK_MEMPOOL
  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_THREAD_SAFE_LOCALE
  Locally applied patches​:
  5ad9dc4e4c9af0670b9d5374504d93a5d9fd0239
  Built under MSWin32
  Compiled at Apr 4 2019 21​:51​:08
  @​INC​:
  D​:/Dev/Git/perl/lib

[p5pRT]

From @steve-m-hay

out.txt.gz

[p5pRT]

From @khwilliamson

On 4/4/19 3​:09 PM, Steve Hay wrote​:

On Thu, 4 Apr 2019 at 21​:23, Karl Williamson <public@​khwilliamson.com> wrote​:

On 4/3/19 11​:00 AM, Steve Hay (via RT) wrote​:

# New Ticket Created by Steve Hay
# Please include the string​: [perl #133981]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133981 >

This is a bug report for perl from steve.m.hay@​googlemail.com,
generated with the help of perlbug 1.41 running under perl 5.29.10.

-----------------------------------------------------------------
[Please describe your issue here]

Blead is currently crashing at the end of ext/XS-APItest/t/locale.t on
Windows (this is Windows 10).

I get the same result using VC14 and VC14.1, but VC12 and MinGW-w64
GCC 7.1.0 work fine, all x64.

Verbose output​:

../ext/XS-APItest/t/locale.t ..
ok 1 - Gconvert doesn't recognize underlying locale outside 'use locale'
ok 2 - Gconvert doesn't recognize underlying locale inside 'use locale'
Dubious, test returned 9 (wstat 2304, 0x900)
All 2 subtests passed

Test Summary Report
-------------------
../ext/XS-APItest/t/locale.t (Wstat​: 2304 Tests​: 2 Failed​: 0)
Non-zero exit status​: 9
Parse errors​: No plan found in TAP output
Files=1, Tests=2, 3 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)
Result​: FAIL

Since I don't have access to a box where this is failing, this will take
some back and forth effort.

Let's start by running this single test manually on a DEBUGGING build
with -DL and sending me the output.

STDERR output from the following is attached, along with the
corresponding perl -V​:

D​:\Dev\Git\perl\ext\XS-APItest>..\..\perl -DL t\locale.t 2>out.txt
ok 1 - Gconvert doesn't recognize underlying locale outside 'use locale'
ok 2 - Gconvert doesn't recognize underlying locale inside 'use locale'

Thanks for that. I think I now know what the problem is. To confirm,
run the same test but use this branch

https://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-me/khw-133981

[p5pRT]

From @khwilliamson

On 4/4/19 3​:40 PM, Karl Williamson wrote​:

On 4/4/19 3​:09 PM, Steve Hay wrote​:

On Thu, 4 Apr 2019 at 21​:23, Karl Williamson <public@​khwilliamson.com>
wrote​:

On 4/3/19 11​:00 AM, Steve Hay (via RT) wrote​:

# New Ticket Created by  Steve Hay
# Please include the string​:  [perl #133981]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133981 >

This is a bug report for perl from steve.m.hay@​googlemail.com,
generated with the help of perlbug 1.41 running under perl 5.29.10.

-----------------------------------------------------------------
[Please describe your issue here]

Blead is currently crashing at the end of ext/XS-APItest/t/locale.t on
Windows (this is Windows 10).

I get the same result using VC14 and VC14.1, but VC12 and MinGW-w64
GCC 7.1.0 work fine, all x64.

Verbose output​:

../ext/XS-APItest/t/locale.t ..
ok 1 - Gconvert doesn't recognize underlying locale outside 'use
locale'
ok 2 - Gconvert doesn't recognize underlying locale inside 'use locale'
Dubious, test returned 9 (wstat 2304, 0x900)
All 2 subtests passed

Test Summary Report
-------------------
../ext/XS-APItest/t/locale.t (Wstat​: 2304 Tests​: 2 Failed​: 0)
    Non-zero exit status​: 9
    Parse errors​: No plan found in TAP output
Files=1, Tests=2,  3 wallclock secs ( 0.00 usr +  0.00 sys =  0.00 CPU)
Result​: FAIL

Since I don't have access to a box where this is failing, this will take
some back and forth effort.

Let's start by running this single test manually on a DEBUGGING build
with -DL and sending me the output.

STDERR output from the following is attached, along with the
corresponding perl -V​:

D​:\Dev\Git\perl\ext\XS-APItest>..\..\perl -DL t\locale.t 2>out.txt
ok 1 - Gconvert doesn't recognize underlying locale outside 'use locale'
ok 2 - Gconvert doesn't recognize underlying locale inside 'use locale'

Thanks for that.  I think I now know what the problem is.  To confirm,
run the same test but use this branch

https://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-me/khw-133981

In looking further, I'm not confident that will help. It looks now like
a Windows bug. Try compiling and running the attached C program.

From the trace you gave, that looks like it will print 3 lines, the
first NULL, and the 2nd and 3rd "iso_latin_16". But all three lines
should be the same. If not, its a windows bug. If they are the same,
its back to the drawing board for me.

[p5pRT]

From @khwilliamson

#include <stdio.h>
#include <locale.h>

int
main()
{
    const char * result = setlocale(LC_NUMERIC, "iso_latin_16");
    if (result == NULL) result = "NULL";
    fprintf(stderr, "%d: %s\n", __LINE__, result);

    result = setlocale(LC_ALL, "iso_latin_16");
    if (result == NULL) result = "NULL";
    fprintf(stderr, "%d: %s\n", __LINE__, result);

    result = setlocale(LC_NUMERIC, "iso_latin_16");
    if (result == NULL) result = "NULL";
    fprintf(stderr, "%d: %s\n", __LINE__, result);
}

[p5pRT]

From @steve-m-hay

On Thu, 4 Apr 2019 at 23​:31, Karl Williamson <public@​khwilliamson.com> wrote​:

On 4/4/19 3​:40 PM, Karl Williamson wrote​:

On 4/4/19 3​:09 PM, Steve Hay wrote​:

On Thu, 4 Apr 2019 at 21​:23, Karl Williamson <public@​khwilliamson.com>
wrote​:

On 4/3/19 11​:00 AM, Steve Hay (via RT) wrote​:

# New Ticket Created by Steve Hay
# Please include the string​: [perl #133981]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133981 >

This is a bug report for perl from steve.m.hay@​googlemail.com,
generated with the help of perlbug 1.41 running under perl 5.29.10.

-----------------------------------------------------------------
[Please describe your issue here]

Blead is currently crashing at the end of ext/XS-APItest/t/locale.t on
Windows (this is Windows 10).

I get the same result using VC14 and VC14.1, but VC12 and MinGW-w64
GCC 7.1.0 work fine, all x64.

Verbose output​:

../ext/XS-APItest/t/locale.t ..
ok 1 - Gconvert doesn't recognize underlying locale outside 'use
locale'
ok 2 - Gconvert doesn't recognize underlying locale inside 'use locale'
Dubious, test returned 9 (wstat 2304, 0x900)
All 2 subtests passed

Test Summary Report
-------------------
../ext/XS-APItest/t/locale.t (Wstat​: 2304 Tests​: 2 Failed​: 0)
Non-zero exit status​: 9
Parse errors​: No plan found in TAP output
Files=1, Tests=2, 3 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)
Result​: FAIL

Since I don't have access to a box where this is failing, this will take
some back and forth effort.

Let's start by running this single test manually on a DEBUGGING build
with -DL and sending me the output.

STDERR output from the following is attached, along with the
corresponding perl -V​:

D​:\Dev\Git\perl\ext\XS-APItest>..\..\perl -DL t\locale.t 2>out.txt
ok 1 - Gconvert doesn't recognize underlying locale outside 'use locale'
ok 2 - Gconvert doesn't recognize underlying locale inside 'use locale'

Thanks for that. I think I now know what the problem is. To confirm,
run the same test but use this branch

https://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-me/khw-133981

In looking further, I'm not confident that will help. It looks now like
a Windows bug. Try compiling and running the attached C program.

From the trace you gave, that looks like it will print 3 lines, the
first NULL, and the 2nd and 3rd "iso_latin_16". But all three lines
should be the same. If not, its a windows bug. If they are the same,
its back to the drawing board for me.

You are correct​: With VC14, VC14.1 and VC14.2 (VS2015, VS2017 and VS2019)​:

9​: NULL
13​: iso_latin_16
17​: iso_latin_16

With VC6 thru VC12 (VC++ 6.0 thru VS2013)​:

9​: NULL
13​: NULL
17​: NULL

So, being a Windows (actually, recent VC++?) problem, I'll report it
to Microsoft :-)

Thanks for diagnosing.

Meanwhile, we should skip the tests (or mark them as TODO) for VC14+.
That's $Config​::Config{ccversion} >= 19.x.y. I'll look at doing that
later.

[p5pRT]

From @steve-m-hay

On Thu, 4 Apr 2019 at 22​:40, Karl Williamson <public@​khwilliamson.com> wrote​:

On 4/4/19 3​:09 PM, Steve Hay wrote​:

On Thu, 4 Apr 2019 at 21​:23, Karl Williamson <public@​khwilliamson.com> wrote​:

On 4/3/19 11​:00 AM, Steve Hay (via RT) wrote​:

# New Ticket Created by Steve Hay
# Please include the string​: [perl #133981]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133981 >

This is a bug report for perl from steve.m.hay@​googlemail.com,
generated with the help of perlbug 1.41 running under perl 5.29.10.

-----------------------------------------------------------------
[Please describe your issue here]

Blead is currently crashing at the end of ext/XS-APItest/t/locale.t on
Windows (this is Windows 10).

I get the same result using VC14 and VC14.1, but VC12 and MinGW-w64
GCC 7.1.0 work fine, all x64.

Verbose output​:

../ext/XS-APItest/t/locale.t ..
ok 1 - Gconvert doesn't recognize underlying locale outside 'use locale'
ok 2 - Gconvert doesn't recognize underlying locale inside 'use locale'
Dubious, test returned 9 (wstat 2304, 0x900)
All 2 subtests passed

Test Summary Report
-------------------
../ext/XS-APItest/t/locale.t (Wstat​: 2304 Tests​: 2 Failed​: 0)
Non-zero exit status​: 9
Parse errors​: No plan found in TAP output
Files=1, Tests=2, 3 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)
Result​: FAIL

Since I don't have access to a box where this is failing, this will take
some back and forth effort.

Let's start by running this single test manually on a DEBUGGING build
with -DL and sending me the output.

STDERR output from the following is attached, along with the
corresponding perl -V​:

D​:\Dev\Git\perl\ext\XS-APItest>..\..\perl -DL t\locale.t 2>out.txt
ok 1 - Gconvert doesn't recognize underlying locale outside 'use locale'
ok 2 - Gconvert doesn't recognize underlying locale inside 'use locale'

Thanks for that. I think I now know what the problem is. To confirm,
run the same test but use this branch

https://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-me/khw-133981

Just for completeness, though we're not expecting success here now
anyway, here is the output from the same test on that branch.

[p5pRT]

From @steve-m-hay

out.txt.gz

[p5pRT]

From @steve-m-hay

On Fri, 5 Apr 2019 at 08​:25, Steve Hay <steve.m.hay@​googlemail.com> wrote​:

On Thu, 4 Apr 2019 at 23​:31, Karl Williamson <public@​khwilliamson.com> wrote​:

On 4/4/19 3​:40 PM, Karl Williamson wrote​:

On 4/4/19 3​:09 PM, Steve Hay wrote​:

On Thu, 4 Apr 2019 at 21​:23, Karl Williamson <public@​khwilliamson.com>
wrote​:

On 4/3/19 11​:00 AM, Steve Hay (via RT) wrote​:

# New Ticket Created by Steve Hay
# Please include the string​: [perl #133981]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133981 >

This is a bug report for perl from steve.m.hay@​googlemail.com,
generated with the help of perlbug 1.41 running under perl 5.29.10.

-----------------------------------------------------------------
[Please describe your issue here]

Blead is currently crashing at the end of ext/XS-APItest/t/locale.t on
Windows (this is Windows 10).

I get the same result using VC14 and VC14.1, but VC12 and MinGW-w64
GCC 7.1.0 work fine, all x64.

Verbose output​:

../ext/XS-APItest/t/locale.t ..
ok 1 - Gconvert doesn't recognize underlying locale outside 'use
locale'
ok 2 - Gconvert doesn't recognize underlying locale inside 'use locale'
Dubious, test returned 9 (wstat 2304, 0x900)
All 2 subtests passed

Test Summary Report
-------------------
../ext/XS-APItest/t/locale.t (Wstat​: 2304 Tests​: 2 Failed​: 0)
Non-zero exit status​: 9
Parse errors​: No plan found in TAP output
Files=1, Tests=2, 3 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)
Result​: FAIL

Since I don't have access to a box where this is failing, this will take
some back and forth effort.

Let's start by running this single test manually on a DEBUGGING build
with -DL and sending me the output.

STDERR output from the following is attached, along with the
corresponding perl -V​:

D​:\Dev\Git\perl\ext\XS-APItest>..\..\perl -DL t\locale.t 2>out.txt
ok 1 - Gconvert doesn't recognize underlying locale outside 'use locale'
ok 2 - Gconvert doesn't recognize underlying locale inside 'use locale'

Thanks for that. I think I now know what the problem is. To confirm,
run the same test but use this branch

https://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-me/khw-133981

In looking further, I'm not confident that will help. It looks now like
a Windows bug. Try compiling and running the attached C program.

From the trace you gave, that looks like it will print 3 lines, the
first NULL, and the 2nd and 3rd "iso_latin_16". But all three lines
should be the same. If not, its a windows bug. If they are the same,
its back to the drawing board for me.

You are correct​: With VC14, VC14.1 and VC14.2 (VS2015, VS2017 and VS2019)​:

9​: NULL
13​: iso_latin_16
17​: iso_latin_16

With VC6 thru VC12 (VC++ 6.0 thru VS2013)​:

9​: NULL
13​: NULL
17​: NULL

So, being a Windows (actually, recent VC++?) problem, I'll report it
to Microsoft :-)

Now reported here​:

https://developercommunity.visualstudio.com/content/problem/519486/setlocalelc-numeric-iso-latin-16-fails-then-succee.html

[p5pRT]

From @steve-m-hay

On Fri, 05 Apr 2019 01​:06​:09 -0700, shay wrote​:

On Fri, 5 Apr 2019 at 08​:25, Steve Hay <steve.m.hay@​googlemail.com>
wrote​:

On Thu, 4 Apr 2019 at 23​:31, Karl Williamson
<public@​khwilliamson.com> wrote​:

On 4/4/19 3​:40 PM, Karl Williamson wrote​:

On 4/4/19 3​:09 PM, Steve Hay wrote​:

On Thu, 4 Apr 2019 at 21​:23, Karl Williamson
<public@​khwilliamson.com>
wrote​:

On 4/3/19 11​:00 AM, Steve Hay (via RT) wrote​:

# New Ticket Created by Steve Hay
# Please include the string​: [perl #133981]
# in the subject line of all future correspondence about this
issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133981 >

This is a bug report for perl from steve.m.hay@​googlemail.com,
generated with the help of perlbug 1.41 running under perl
5.29.10.

-----------------------------------------------------------------
[Please describe your issue here]

Blead is currently crashing at the end of ext/XS-
APItest/t/locale.t on
Windows (this is Windows 10).

I get the same result using VC14 and VC14.1, but VC12 and
MinGW-w64
GCC 7.1.0 work fine, all x64.

Verbose output​:

../ext/XS-APItest/t/locale.t ..
ok 1 - Gconvert doesn't recognize underlying locale outside
'use
locale'
ok 2 - Gconvert doesn't recognize underlying locale inside
'use locale'
Dubious, test returned 9 (wstat 2304, 0x900)
All 2 subtests passed

Test Summary Report
-------------------
../ext/XS-APItest/t/locale.t (Wstat​: 2304 Tests​: 2 Failed​: 0)
Non-zero exit status​: 9
Parse errors​: No plan found in TAP output
Files=1, Tests=2, 3 wallclock secs ( 0.00 usr + 0.00 sys =
0.00 CPU)
Result​: FAIL

Since I don't have access to a box where this is failing, this
will take
some back and forth effort.

Let's start by running this single test manually on a DEBUGGING
build
with -DL and sending me the output.

STDERR output from the following is attached, along with the
corresponding perl -V​:

D​:\Dev\Git\perl\ext\XS-APItest>..\..\perl -DL t\locale.t
2>out.txt
ok 1 - Gconvert doesn't recognize underlying locale outside 'use
locale'
ok 2 - Gconvert doesn't recognize underlying locale inside 'use
locale'

Thanks for that. I think I now know what the problem is. To
confirm,
run the same test but use this branch

https://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-
me/khw-133981

In looking further, I'm not confident that will help. It looks now
like
a Windows bug. Try compiling and running the attached C program.

From the trace you gave, that looks like it will print 3 lines, the
first NULL, and the 2nd and 3rd "iso_latin_16". But all three
lines
should be the same. If not, its a windows bug. If they are the
same,
its back to the drawing board for me.

You are correct​: With VC14, VC14.1 and VC14.2 (VS2015, VS2017 and
VS2019)​:

9​: NULL
13​: iso_latin_16
17​: iso_latin_16

With VC6 thru VC12 (VC++ 6.0 thru VS2013)​:

9​: NULL
13​: NULL
17​: NULL

So, being a Windows (actually, recent VC++?) problem, I'll report it
to Microsoft :-)

Now reported here​:

https://developercommunity.visualstudio.com/content/problem/519486/setlocalelc-
numeric-iso-latin-16-fails-then-succee.html

An update on that page acknowledges this as a regression in the Universal CRT introduced in the Windows 10 April 2018 Update. It will be fixed in the May 2019 update.

[p5pRT]

From @khwilliamson

On Fri, 26 Apr 2019 00​:09​:18 -0700, shay wrote​:

On Fri, 05 Apr 2019 01​:06​:09 -0700, shay wrote​:

On Fri, 5 Apr 2019 at 08​:25, Steve Hay <steve.m.hay@​googlemail.com>
wrote​:

On Thu, 4 Apr 2019 at 23​:31, Karl Williamson
<public@​khwilliamson.com> wrote​:

On 4/4/19 3​:40 PM, Karl Williamson wrote​:

On 4/4/19 3​:09 PM, Steve Hay wrote​:

On Thu, 4 Apr 2019 at 21​:23, Karl Williamson
<public@​khwilliamson.com>
wrote​:

On 4/3/19 11​:00 AM, Steve Hay (via RT) wrote​:

# New Ticket Created by Steve Hay
# Please include the string​: [perl #133981]
# in the subject line of all future correspondence about
this
issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133981 >

This is a bug report for perl from
steve.m.hay@​googlemail.com,
generated with the help of perlbug 1.41 running under perl
5.29.10.

-----------------------------------------------------------------
[Please describe your issue here]

Blead is currently crashing at the end of ext/XS-
APItest/t/locale.t on
Windows (this is Windows 10).

I get the same result using VC14 and VC14.1, but VC12 and
MinGW-w64
GCC 7.1.0 work fine, all x64.

Verbose output​:

../ext/XS-APItest/t/locale.t ..
ok 1 - Gconvert doesn't recognize underlying locale outside
'use
locale'
ok 2 - Gconvert doesn't recognize underlying locale inside
'use locale'
Dubious, test returned 9 (wstat 2304, 0x900)
All 2 subtests passed

Test Summary Report
-------------------
../ext/XS-APItest/t/locale.t (Wstat​: 2304 Tests​: 2 Failed​:
0)
Non-zero exit status​: 9
Parse errors​: No plan found in TAP output
Files=1, Tests=2, 3 wallclock secs ( 0.00 usr + 0.00 sys =
0.00 CPU)
Result​: FAIL

Since I don't have access to a box where this is failing,
this
will take
some back and forth effort.

Let's start by running this single test manually on a
DEBUGGING
build
with -DL and sending me the output.

STDERR output from the following is attached, along with the
corresponding perl -V​:

D​:\Dev\Git\perl\ext\XS-APItest>..\..\perl -DL t\locale.t
2> out.txt
ok 1 - Gconvert doesn't recognize underlying locale outside
'use
locale'
ok 2 - Gconvert doesn't recognize underlying locale inside
'use
locale'

Thanks for that. I think I now know what the problem is. To
confirm,
run the same test but use this branch

https://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-
me/khw-133981

In looking further, I'm not confident that will help. It looks
now
like
a Windows bug. Try compiling and running the attached C program.

From the trace you gave, that looks like it will print 3 lines,
the
first NULL, and the 2nd and 3rd "iso_latin_16". But all three
lines
should be the same. If not, its a windows bug. If they are the
same,
its back to the drawing board for me.

You are correct​: With VC14, VC14.1 and VC14.2 (VS2015, VS2017 and
VS2019)​:

9​: NULL
13​: iso_latin_16
17​: iso_latin_16

With VC6 thru VC12 (VC++ 6.0 thru VS2013)​:

9​: NULL
13​: NULL
17​: NULL

So, being a Windows (actually, recent VC++?) problem, I'll report
it
to Microsoft :-)

Now reported here​:

https://developercommunity.visualstudio.com/content/problem/519486/setlocalelc-
numeric-iso-latin-16-fails-then-succee.html

An update on that page acknowledges this as a regression in the
Universal CRT introduced in the Windows 10 April 2018 Update. It will
be fixed in the May 2019 update.

So what do we do about this ticket? Its out of our hands. I don't see a work around possible. I'm guessing everybody gets this fix as part of Windows Update.
--
Karl Williamson