Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
p5pRT opened this issue Apr 3, 2019 · 43 comments
Closed

Comments

@p5pRT
Copy link

p5pRT commented Apr 3, 2019

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

Searchable as RT133981$

@p5pRT
Copy link
Author

p5pRT commented Apr 3, 2019

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
Copy link
Author

p5pRT commented Apr 4, 2019

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
Copy link
Author

p5pRT commented Apr 4, 2019

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

@p5pRT
Copy link
Author

p5pRT commented Apr 4, 2019

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
Copy link
Author

p5pRT commented Apr 4, 2019

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
Copy link
Author

p5pRT commented Apr 4, 2019

From @steve-m-hay

out.txt.gz

@p5pRT
Copy link
Author

p5pRT commented Apr 4, 2019

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
Copy link
Author

p5pRT commented Apr 4, 2019

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
Copy link
Author

p5pRT commented Apr 4, 2019

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
Copy link
Author

p5pRT commented Apr 5, 2019

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
Copy link
Author

p5pRT commented Apr 5, 2019

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
Copy link
Author

p5pRT commented Apr 5, 2019

From @steve-m-hay

out.txt.gz

@p5pRT
Copy link
Author

p5pRT commented Apr 5, 2019

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
Copy link
Author

p5pRT commented Apr 26, 2019

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
Copy link
Author

p5pRT commented Apr 30, 2019

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

@p5pRT
Copy link
Author

p5pRT commented Apr 30, 2019

From @steve-m-hay

On Mon, 29 Apr 2019 17​:06​:17 -0700, khw wrote​:

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.

I think so. I've updated README.win32 in commit 7115365 to note the impending fix. I will leave the ticket open for now. Hopefully I'll get the update the next month or so and if it works then I'll close the ticket then.

(I don't think a suggestion I made earlier in this ticket to skip the tests for VC++ 14 and above is a good idea since it would now require testing for the Windows 10 Update version in the skip logic, which isn't worth the hassle with a fix on the way soon anyway.)

@p5pRT
Copy link
Author

p5pRT commented Jun 27, 2019

From @khwilliamson

On Tue, 30 Apr 2019 09​:44​:23 -0700, shay wrote​:

On Mon, 29 Apr 2019 17​:06​:17 -0700, khw wrote​:

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.

I think so. I've updated README.win32 in commit
7115365 to note the impending fix. I
will leave the ticket open for now. Hopefully I'll get the update the
next month or so and if it works then I'll close the ticket then.

(I don't think a suggestion I made earlier in this ticket to skip the
tests for VC++ 14 and above is a good idea since it would now require
testing for the Windows 10 Update version in the skip logic, which
isn't worth the hassle with a fix on the way soon anyway.)

I believe the fix is out. Can someone verify if this is still an issue?
--
Karl Williamson

@p5pRT
Copy link
Author

p5pRT commented Jul 4, 2019

From @steve-m-hay

On Thu, 27 Jun 2019 09​:25​:27 -0700, khw wrote​:

On Tue, 30 Apr 2019 09​:44​:23 -0700, shay wrote​:

On Mon, 29 Apr 2019 17​:06​:17 -0700, khw wrote​:

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.

I think so. I've updated README.win32 in commit
7115365 to note the impending fix. I
will leave the ticket open for now. Hopefully I'll get the update the
next month or so and if it works then I'll close the ticket then.

(I don't think a suggestion I made earlier in this ticket to skip the
tests for VC++ 14 and above is a good idea since it would now require
testing for the Windows 10 Update version in the skip logic, which
isn't worth the hassle with a fix on the way soon anyway.)

I believe the fix is out. Can someone verify if this is still an
issue?

I've updated to Windows 10 May 2019 (Version 1903) and now the shay.c program that you sent previously produces the same output with VC14.2 as it does with VC6-VC12, namely​:

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

However, our test script still crashes as before!​:

D​:\Dev\Git\perl\t>.\perl harness ..\ext\XS-APItest\t\locale.t
../ext/XS-APItest/t/locale.t .. 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.01 sys = 0.01 CPU)
Result​: FAIL

New -DL output attached.

The crash is here​:

  ucrtbase.dll!00007ff88794bcf8() Unknown
  ucrtbase.dll!00007ff88792b84a() Unknown
  ucrtbase.dll!00007ff8878ec165() Unknown
  ucrtbase.dll!00007ff8878ec10f() Unknown
  ucrtbase.dll!00007ff8878ec0c7() Unknown

perl531.dll!S_win32_setlocale(interpreter * my_perl, int category, const char * locale) Line 2144 C
  perl531.dll!Perl_setlocale(const int category, const char * locale) Line 2272 C
  POSIX.dll!XS_POSIX_setlocale(interpreter * my_perl, cv * cv) Line 2277 C
  perl531.dll!Perl_pp_entersub(interpreter * my_perl) Line 5240 C
  perl531.dll!Perl_runops_debug(interpreter * my_perl) Line 2537 C
  perl531.dll!S_run_body(interpreter * my_perl, long oldscope) Line 2714 C
  perl531.dll!perl_run(interpreter * my_perl) Line 2638 C
  perl531.dll!RunPerl(int argc, char * * argv, char * * env) Line 217 C++
  perl.exe!main(int argc, char * * argv, char * * env) Line 40 C
  [External Code]

The code is​:
result = setlocale(category, locale);
where category is 0 and locale is "Français".

The exception text is​:
Unhandled exception at 0x00007FF88794BCF8 (ucrtbase.dll) in perl.exe​: An invalid parameter was passed to a function that considers invalid parameters fatal.

I'm not sure what the problem is here now. If I build and run this​:

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

int
main()
{
  const char * result = setlocale(0, "Français");
  if (result == NULL) result = "NULL";
  fprintf(stderr, "%d​: %s\n", __LINE__, result);
}

then there is no crash. The output is simply​:

9​: NULL

@p5pRT
Copy link
Author

p5pRT commented Jul 4, 2019

From @steve-m-hay

out.txt.gz

@p5pRT
Copy link
Author

p5pRT commented Jul 23, 2019

From @tonycoz

Created by @tonycoz

While testing perl on Windows 10 x64 I saw ext/XS-APItest/t/locale.t
failing.

On further tracing this appeared to be aborting on a setlocale() call in
t/loc_tools.pl in _trylocale().

On running the test in the debugger (after rebuild with CFG=DebugFull, and
tracking down the CRT source) I managed to get a back trace.

This appears to be failing when the CRT is internally trying to convert a
locale name of "Catal\x{e0}" from a narrow string to a wide string.

From the CRT source in setlocale.cpp​:

extern "C" static wchar_t* __cdecl call_wsetlocale(int const category, char const* const narrow_locale)
{
  if (narrow_locale == nullptr)
  return _wsetlocale(category, nullptr);

  size_t size;
  _ERRCHECK_EINVAL_ERANGE(mbstowcs_s(&size, nullptr, 0, narrow_locale, INT_MAX));

  __crt_unique_heap_ptr<wchar_t> wide_locale(_calloc_crt_t(wchar_t, size));
  if (wide_locale.get() == nullptr)
  return nullptr;

-->> exception thrown by this check
  if (_ERRCHECK_EINVAL_ERANGE(mbstowcs_s(nullptr, wide_locale.get(), size, narrow_locale, _TRUNCATE)) != 0)
  return nullptr;

  return _wsetlocale(category, wide_locale.get());
}

At the point of the exception size is zero, and wide_locale's pointer is
non-NULL, which mbstowcs_s() fails.

I suspect the first sizing mbstowcs_s() call is failing because the current locale
isn't the C locale, and the failing string isn't validly encoded in that current
locale, which messes it up for the second call.

It may be the the win32 specific code should be using _wsetlocal() instead of
setlocale() to avoid this conversion, of specifically set LC_CTYPE to the C
locale.

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl 5.31.3:

Configured by tony at Tue Jul 23 15:45:08 2019.

Summary of my perl5 (revision 5 version 31 subversion 3) configuration:
   
  Platform:
    osname=MSWin32
    osvers=10.0.17134.885
    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 -MDd -Zi -D_DEBUG -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 -DUSE_PERLIO'
    optimize='-Od -MDd -Zi -D_DEBUG -DDEBUGGING -fp:precise'
    cppflags='-DWIN32'
    ccversion='19.20.27508.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 -libpath:"c:\perl\lib\CORE" -machine:AMD64 -subsystem:console,"5.02"'
    libpth="C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.20.27508\\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 msvcrtd.lib vcruntimed.lib ucrtd.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 msvcrtd.lib vcruntimed.lib ucrtd.lib
    libc=ucrtd.lib
    so=dll
    useshrplib=true
    libperl=perl531.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"'



@INC for perl 5.31.3:
    C:/Users/Tony/dev/perl/git/perl/lib


Environment for perl 5.31.3:
    HOME (unset)
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.20.27508\bin\HostX64\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\VC\VCPackages;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\bin\Roslyn;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Team Tools\Performance Tools\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Team Tools\Performance Tools;C:\Program Files (x86)\Microsoft Visual Studio\Shared\Common\VSPerfCollectionTools\vs2019\\x64;C:\Program Files (x86)\Microsoft Visual
Studio\Shared\Common\VSPerfCollectionTools\vs2019\;C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\;C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64;C:\Program Files (x86)\Windows Kits\10\bin\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\\MSBuild\Current\Bin;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Tools\;C:\Program Files\Microsoft MPI\Bin\;C:\Program Files (x86)\Common Files\Intel\Shared Files\cpp\bin\Intel64;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\dotnet\;C:\Program Files\Git\cmd;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\Microsoft SQL
Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Users\Tony\AppData\Local\Microsoft\WindowsApps;C:\Users\Tony\AppData\Local\GitHubDesktop\bin;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja;c:\sperl-5.28.1.1-64bit-portable\c\bin
    PERL_BADLANG (unset)
    SHELL (unset)

@p5pRT
Copy link
Author

p5pRT commented Jul 23, 2019

From @steve-m-hay

On Mon, 22 Jul 2019 23​:29​:59 -0700, tonyc wrote​:

This is a bug report for perl from tony@​develop-help.com,
generated with the help of perlbug 1.41 running under perl 5.31.3.

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

While testing perl on Windows 10 x64 I saw ext/XS-APItest/t/locale.t
failing.

This is a duplicate of https​://rt.perl.org/Ticket/Display.html?id=133981, which is documented in README.win32​: https://perl5.git.perl.org/perl.git/commit/7115365105

You've debugged it further than me though :-)

Do you have the May 2019 Update on your machine?

@p5pRT
Copy link
Author

p5pRT commented Jul 23, 2019

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

@p5pRT
Copy link
Author

p5pRT commented Jul 23, 2019

From @tonycoz

On Tue, 23 Jul 2019 00​:07​:47 -0700, shay wrote​:

On Mon, 22 Jul 2019 23​:29​:59 -0700, tonyc wrote​:

This is a bug report for perl from tony@​develop-help.com,
generated with the help of perlbug 1.41 running under perl 5.31.3.

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

While testing perl on Windows 10 x64 I saw ext/XS-APItest/t/locale.t
failing.

This is a duplicate of
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133981, which is documented
in README.win32​: https://perl5.git.perl.org/perl.git/commit/7115365105

Oops, I've merged them.

You've debugged it further than me though :-)

Do you have the May 2019 Update on your machine?

I don't think I'd used it since I set up this machine in February.

I'm updating now, though that might require a reboot.

Tony

@p5pRT
Copy link
Author

p5pRT commented Jul 23, 2019

From @tonycoz

On Tue, 23 Jul 2019 04​:09​:07 -0700, tonyc wrote​:

On Tue, 23 Jul 2019 00​:07​:47 -0700, shay wrote​:

On Mon, 22 Jul 2019 23​:29​:59 -0700, tonyc wrote​:

This is a bug report for perl from tony@​develop-help.com,
generated with the help of perlbug 1.41 running under perl 5.31.3.

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

While testing perl on Windows 10 x64 I saw ext/XS-APItest/t/locale.t
failing.

This is a duplicate of
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133981, which is documented
in README.win32​: https://perl5.git.perl.org/perl.git/commit/7115365105

Oops, I've merged them.

You've debugged it further than me though :-)

Do you have the May 2019 Update on your machine?

I don't think I'd used it since I set up this machine in February.

I'm updating now, though that might require a reboot.

Found a chance to reboot.

Rebuilt with

gmake -j3 CCTYPE=MSVC142 CFG=DebugFull test TEST_FILES=../ext/XS-APItest/t/locale.t

but it still fails, on the same name​:

Invalid parameter detected in function _mbstowcs_s_l. File​: minkernel\crts\ucrt\src\appcrt\convert\mbstowcs.cpp, line​: 246
Expression​: (pwcs == nullptr && sizeInWords == 0) || (pwcs != nullptr && sizeInWords > 0)
../ext/XS-APItest/t/locale.t .. Dubious, test returned 9 (wstat 2304, 0x900)

I'll have a play with a fix tomorrow, probably using _wsetlocale().

Tony

@p5pRT
Copy link
Author

p5pRT commented Jul 24, 2019

From @tonycoz

On Tue, 23 Jul 2019 04​:54​:07 -0700, tonyc wrote​:

On Tue, 23 Jul 2019 04​:09​:07 -0700, tonyc wrote​:

On Tue, 23 Jul 2019 00​:07​:47 -0700, shay wrote​:

On Mon, 22 Jul 2019 23​:29​:59 -0700, tonyc wrote​:

This is a bug report for perl from tony@​develop-help.com,
generated with the help of perlbug 1.41 running under perl
5.31.3.

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

While testing perl on Windows 10 x64 I saw ext/XS-
APItest/t/locale.t
failing.

This is a duplicate of
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133981, which is
documented
in README.win32​:
https://perl5.git.perl.org/perl.git/commit/7115365105

Oops, I've merged them.

You've debugged it further than me though :-)

Do you have the May 2019 Update on your machine?

I don't think I'd used it since I set up this machine in February.

I'm updating now, though that might require a reboot.

Found a chance to reboot.

It turns out I misunderstood the question - I'm running version 1803 of Windows 10.

I'm on the "Semi-Annual Channel" rather than the oh so clearly named "Semi-Annual Channel (Targeted)".

So I still have the buggy crt, I'm not sure this is worth us fixing.

Tony

@p5pRT
Copy link
Author

p5pRT commented Jul 24, 2019

From @tonycoz

On Tue, 23 Jul 2019 17​:12​:25 -0700, tonyc wrote​:

On Tue, 23 Jul 2019 04​:54​:07 -0700, tonyc wrote​:

On Tue, 23 Jul 2019 04​:09​:07 -0700, tonyc wrote​:

On Tue, 23 Jul 2019 00​:07​:47 -0700, shay wrote​:

On Mon, 22 Jul 2019 23​:29​:59 -0700, tonyc wrote​:

This is a bug report for perl from tony@​develop-help.com,
generated with the help of perlbug 1.41 running under perl
5.31.3.

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

While testing perl on Windows 10 x64 I saw ext/XS-
APItest/t/locale.t
failing.

This is a duplicate of
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133981, which is
documented
in README.win32​:
https://perl5.git.perl.org/perl.git/commit/7115365105

Oops, I've merged them.

You've debugged it further than me though :-)

Do you have the May 2019 Update on your machine?

I don't think I'd used it since I set up this machine in February.

I'm updating now, though that might require a reboot.

Found a chance to reboot.

It turns out I misunderstood the question - I'm running version 1803
of Windows 10.

I'm on the "Semi-Annual Channel" rather than the oh so clearly named
"Semi-Annual Channel (Targeted)".

So I still have the buggy crt, I'm not sure this is worth us fixing.

A reply didn't make it to the ticket​:

https://www.nntp.perl.org/group/perl.perl5.porters/2019/07/msg255688.html

indicating that 1903 didn't fix it.

So here's a rough patch.

Tony

@p5pRT
Copy link
Author

p5pRT commented Jul 24, 2019

From @tonycoz

0001-perl-133981-rough-fix-for-strange-setlocale-abort.patch
From 0048db520669535dcd911bfe5dbc3029a8a7cf45 Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Wed, 24 Jul 2019 15:56:08 +1000
Subject: (perl #133981) rough fix for strange setlocale() abort

The part that aborts is the wrapper that converts the CRT setlocale()
call into a call to _wsetlocale(), so replace that.

Rough in that:
 - I haven't tested on non-MSVC 2019 (yet)
 - it always uses CP_UTF8 - is that the correct solution?
 - the return value is freed on the next LEAVE
---
 locale.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)

diff --git a/locale.c b/locale.c
index db83d993de..ebd1533425 100644
--- a/locale.c
+++ b/locale.c
@@ -2084,6 +2084,57 @@ S_new_collate(pTHX_ const char *newcoll)
 
 #ifdef WIN32
 
+#define USE_WSETLOCALE
+
+#ifdef USE_WSETLOCALE
+
+STATIC char *
+S_wrap_wsetlocale(pTHX_ int category, const char *locale) {
+    wchar_t *wlocale;
+    wchar_t *wresult;
+    char *result;
+
+    if (locale) {
+        int req_size =
+            MultiByteToWideChar(CP_UTF8, 0, locale, -1, NULL, 0);
+
+        if (!req_size) {
+            errno = EINVAL;
+            return NULL;
+        }
+
+        Newx(wlocale, req_size, wchar_t);
+        if (!MultiByteToWideChar(CP_UTF8, 0, locale, -1, wlocale, req_size)) {
+            Safefree(wlocale);
+            errno = EINVAL;
+            return NULL;
+        }
+    }
+    else {
+        wlocale = NULL;
+    }
+    wresult = _wsetlocale(category, wlocale);
+    Safefree(wlocale);
+    if (wresult) {
+        int req_size =
+            WideCharToMultiByte(CP_UTF8, 0, wresult, -1, NULL, 0, NULL, NULL);
+        Newx(result, req_size, char);
+        SAVEFREEPV(result); /* is there something better we can do here? */
+        if (!WideCharToMultiByte(CP_UTF8, 0, wresult, -1,
+                                 result, req_size, NULL, NULL)) {
+            errno = EINVAL;
+            return NULL;
+        }
+    }
+    else {
+        result = NULL;
+    }
+
+    return result;
+}
+
+#endif
+
 STATIC char *
 S_win32_setlocale(pTHX_ int category, const char* locale)
 {
@@ -2141,7 +2192,11 @@ S_win32_setlocale(pTHX_ int category, const char* locale)
 
     }
 
+#ifdef USE_WSETLOCALE
+    result = S_wrap_wsetlocale(aTHX_ category, locale);
+#else
     result = setlocale(category, locale);
+#endif
     DEBUG_L(STMT_START {
                 dSAVE_ERRNO;
                 PerlIO_printf(Perl_debug_log, "%s:%d: %s\n", __FILE__, __LINE__,
@@ -2162,7 +2217,11 @@ S_win32_setlocale(pTHX_ int category, const char* locale)
     for (i = 0; i < LC_ALL_INDEX; i++) {
         result = PerlEnv_getenv(category_names[i]);
         if (result && strNE(result, "")) {
+#ifdef USE_WSETLOCALE
+            S_wrap_wsetlocale(aTHX_ category, locale);
+#else
             setlocale(categories[i], result);
+#endif
             DEBUG_Lv(PerlIO_printf(Perl_debug_log, "%s:%d: %s\n",
                 __FILE__, __LINE__,
                 setlocale_debug_string(categories[i], result, "not captured")));
-- 
2.20.1.windows.1

@p5pRT
Copy link
Author

p5pRT commented Jul 24, 2019

From @tonycoz

On Tue, 23 Jul 2019 22​:59​:04 -0700, tonyc wrote​:

On Tue, 23 Jul 2019 17​:12​:25 -0700, tonyc wrote​:

On Tue, 23 Jul 2019 04​:54​:07 -0700, tonyc wrote​:

On Tue, 23 Jul 2019 04​:09​:07 -0700, tonyc wrote​:

On Tue, 23 Jul 2019 00​:07​:47 -0700, shay wrote​:

On Mon, 22 Jul 2019 23​:29​:59 -0700, tonyc wrote​:

This is a bug report for perl from tony@​develop-help.com,
generated with the help of perlbug 1.41 running under perl
5.31.3.

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

While testing perl on Windows 10 x64 I saw ext/XS-
APItest/t/locale.t
failing.

This is a duplicate of
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133981, which is
documented
in README.win32​:
https://perl5.git.perl.org/perl.git/commit/7115365105

Oops, I've merged them.

You've debugged it further than me though :-)

Do you have the May 2019 Update on your machine?

I don't think I'd used it since I set up this machine in February.

I'm updating now, though that might require a reboot.

Found a chance to reboot.

It turns out I misunderstood the question - I'm running version 1803
of Windows 10.

I'm on the "Semi-Annual Channel" rather than the oh so clearly named
"Semi-Annual Channel (Targeted)".

So I still have the buggy crt, I'm not sure this is worth us fixing.

A reply didn't make it to the ticket​:

https://www.nntp.perl.org/group/perl.perl5.porters/2019/07/msg255688.html

indicating that 1903 didn't fix it.

So here's a rough patch.

Oops, forgot to mention, while the test no longer crashes, later tests produce Invalid parameter messages from the CRT​:

ok 23 - Returns expected value('AM') for AM_STRInvalid parameter dete
cted in function ok 24 - Returns a value (in this case 'ANSI_X3.4-1968') for CODESETexpand_time
. File​: minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp, line​: 739
ok 25 - Returns a value (in this case '') for CRNCYSTRE
xpression​: timeok 26 - Returns expected value('Sunday') for DAY_1ptr->tm_mday >= 1 && timeptr->tm_mday <= 31

Invalid parameter detected in function ok 27 - Returns expected value('Monday') for DAY_2_
Wcsftime_l. File​: ok 28 - Returns expected value('Tuesday') for DAY_3minkernel\crts\ucrt\src\appcrt\time\wcsftime
.cpp, line​: 1184
ok 29 - Returns expected value('Wednesday') for DAY_4E
xpression​: ok 30 - Returns expected value('Thursday') for DAY_5f
alse
Invalid parameter detected in function ok 31 - Returns expected value('Friday') for DAY_6e
xpand_time. File​: ok 32 - Returns expected value('Saturday') for DAY_7minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp, line​: 739

Expression​: ok 33 - Returns a value (in this case '%x') for D_FMTt
imeptr->tm_mday >= 1 && timeptr->tm_mday <= 31
ok 34 - Returns a value (in this case '%c') for D_T_FMTInvalid parameter detected in function
_Wcsftime_l. File​: minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp, line​: 1184
ok 35 - Returns expected value('') for ERAExpre
ssion​: false

(and more)

This appears to be unrelated to this change.

Tony

@p5pRT
Copy link
Author

p5pRT commented Jul 24, 2019

From @steve-m-hay

On Tue, 23 Jul 2019 22​:59​:04 -0700, tonyc wrote​:

On Tue, 23 Jul 2019 17​:12​:25 -0700, tonyc wrote​:

On Tue, 23 Jul 2019 04​:54​:07 -0700, tonyc wrote​:

On Tue, 23 Jul 2019 04​:09​:07 -0700, tonyc wrote​:

On Tue, 23 Jul 2019 00​:07​:47 -0700, shay wrote​:

On Mon, 22 Jul 2019 23​:29​:59 -0700, tonyc wrote​:

This is a bug report for perl from tony@​develop-help.com,
generated with the help of perlbug 1.41 running under perl
5.31.3.

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

While testing perl on Windows 10 x64 I saw ext/XS-
APItest/t/locale.t
failing.

This is a duplicate of
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133981, which is
documented
in README.win32​:
https://perl5.git.perl.org/perl.git/commit/7115365105

Oops, I've merged them.

You've debugged it further than me though :-)

Do you have the May 2019 Update on your machine?

I don't think I'd used it since I set up this machine in February.

I'm updating now, though that might require a reboot.

Found a chance to reboot.

It turns out I misunderstood the question - I'm running version 1803
of Windows 10.

I'm on the "Semi-Annual Channel" rather than the oh so clearly named
"Semi-Annual Channel (Targeted)".

So I still have the buggy crt, I'm not sure this is worth us fixing.

A reply didn't make it to the ticket​:

https://www.nntp.perl.org/group/perl.perl5.porters/2019/07/msg255688.html

indicating that 1903 didn't fix it.

They did change something, though - see my comment here​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133981#txn-1645106. Maybe there are two separate issues here - one CRT problem which they have fixed (khw's shay.c program now behaves correctly), and one other CRT problem which your patch works around. We should probably tell them about that too and hopefully they'll fix it in some future update (though we still need the workaround for now, of course).

Thanks for the patch. I'll give it a try with some different compiler/OS versions.

@p5pRT
Copy link
Author

p5pRT commented Aug 10, 2019

From @steve-m-hay

On Wed, 24 Jul 2019 00​:14​:12 -0700, shay wrote​:

On Tue, 23 Jul 2019 22​:59​:04 -0700, tonyc wrote​:

On Tue, 23 Jul 2019 17​:12​:25 -0700, tonyc wrote​:

On Tue, 23 Jul 2019 04​:54​:07 -0700, tonyc wrote​:

On Tue, 23 Jul 2019 04​:09​:07 -0700, tonyc wrote​:

On Tue, 23 Jul 2019 00​:07​:47 -0700, shay wrote​:

On Mon, 22 Jul 2019 23​:29​:59 -0700, tonyc wrote​:

This is a bug report for perl from tony@​develop-help.com,
generated with the help of perlbug 1.41 running under perl
5.31.3.

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

While testing perl on Windows 10 x64 I saw ext/XS-
APItest/t/locale.t
failing.

This is a duplicate of
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133981, which is
documented
in README.win32​:
https://perl5.git.perl.org/perl.git/commit/7115365105

Oops, I've merged them.

You've debugged it further than me though :-)

Do you have the May 2019 Update on your machine?

I don't think I'd used it since I set up this machine in
February.

I'm updating now, though that might require a reboot.

Found a chance to reboot.

It turns out I misunderstood the question - I'm running version
1803
of Windows 10.

I'm on the "Semi-Annual Channel" rather than the oh so clearly
named
"Semi-Annual Channel (Targeted)".

So I still have the buggy crt, I'm not sure this is worth us
fixing.

A reply didn't make it to the ticket​:

https://www.nntp.perl.org/group/perl.perl5.porters/2019/07/msg255688.html

indicating that 1903 didn't fix it.

They did change something, though - see my comment here​:
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133981#txn-1645106. Maybe
there are two separate issues here - one CRT problem which they have
fixed (khw's shay.c program now behaves correctly), and one other CRT
problem which your patch works around. We should probably tell them
about that too and hopefully they'll fix it in some future update
(though we still need the workaround for now, of course).

Thanks for the patch. I'll give it a try with some different
compiler/OS versions.

The patch looks good to me, except that the second

S_wrap_wsetlocale(aTHX_ category, locale);

looks like it should be

S_wrap_wsetlocale(aTHX_ categories[i], result);

?

Regardless, it fixes the failures on Windows 10, using VC14, 14.1 and 14.2. I've also tried VC12 on Win10 and all is OK.

On Windows 7 I've tried VC7 and VC14 and all is well.

(I wouldn't worry about the invalid parameter warnings coming out, at least not now, because they're probably not new and there are many other invalid parameter warnings when running the full test suite in a DebugFull build, and always have been ever since that build option was added.)

@p5pRT
Copy link
Author

p5pRT commented Aug 13, 2019

From @tonycoz

On Sat, 10 Aug 2019 05​:53​:14 -0700, shay wrote​:

The patch looks good to me, except that the second

S_wrap_wsetlocale(aTHX_ category, locale);

looks like it should be

S_wrap_wsetlocale(aTHX_ categories[i], result);

?

Updated patch attached.

Regardless, it fixes the failures on Windows 10, using VC14, 14.1 and
14.2. I've also tried VC12 on Win10 and all is OK.

On Windows 7 I've tried VC7 and VC14 and all is well.

Thanks.

Since this fixes tests that are failing, I don't think it needs extra tests.

(I wouldn't worry about the invalid parameter warnings coming out, at
least not now, because they're probably not new and there are many
other invalid parameter warnings when running the full test suite in a
DebugFull build, and always have been ever since that build option was
added.)

Ok.

Tony

@p5pRT
Copy link
Author

p5pRT commented Aug 13, 2019

From @tonycoz

0001-perl-133981-rough-fix-for-strange-setlocale-abort.patch
From 6891872d0c871fe138f992653be06bd771f6c58a Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Wed, 24 Jul 2019 15:56:08 +1000
Subject: (perl #133981) rough fix for strange setlocale() abort

The part that aborts is the wrapper that converts the CRT setlocale()
call into a call to _wsetlocale(), so replace that.

Rough in that:
 - I haven't tested on non-MSVC 2019 (yet)
 - it always uses CP_UTF8 - is that the correct solution?
 - the return value is freed on the next LEAVE
---
 locale.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)

diff --git a/locale.c b/locale.c
index af7af60038..b7c7a3eceb 100644
--- a/locale.c
+++ b/locale.c
@@ -2084,6 +2084,57 @@ S_new_collate(pTHX_ const char *newcoll)
 
 #ifdef WIN32
 
+#define USE_WSETLOCALE
+
+#ifdef USE_WSETLOCALE
+
+STATIC char *
+S_wrap_wsetlocale(pTHX_ int category, const char *locale) {
+    wchar_t *wlocale;
+    wchar_t *wresult;
+    char *result;
+
+    if (locale) {
+        int req_size =
+            MultiByteToWideChar(CP_UTF8, 0, locale, -1, NULL, 0);
+
+        if (!req_size) {
+            errno = EINVAL;
+            return NULL;
+        }
+
+        Newx(wlocale, req_size, wchar_t);
+        if (!MultiByteToWideChar(CP_UTF8, 0, locale, -1, wlocale, req_size)) {
+            Safefree(wlocale);
+            errno = EINVAL;
+            return NULL;
+        }
+    }
+    else {
+        wlocale = NULL;
+    }
+    wresult = _wsetlocale(category, wlocale);
+    Safefree(wlocale);
+    if (wresult) {
+        int req_size =
+            WideCharToMultiByte(CP_UTF8, 0, wresult, -1, NULL, 0, NULL, NULL);
+        Newx(result, req_size, char);
+        SAVEFREEPV(result); /* is there something better we can do here? */
+        if (!WideCharToMultiByte(CP_UTF8, 0, wresult, -1,
+                                 result, req_size, NULL, NULL)) {
+            errno = EINVAL;
+            return NULL;
+        }
+    }
+    else {
+        result = NULL;
+    }
+
+    return result;
+}
+
+#endif
+
 STATIC char *
 S_win32_setlocale(pTHX_ int category, const char* locale)
 {
@@ -2141,7 +2192,11 @@ S_win32_setlocale(pTHX_ int category, const char* locale)
 
     }
 
+#ifdef USE_WSETLOCALE
+    result = S_wrap_wsetlocale(aTHX_ category, locale);
+#else
     result = setlocale(category, locale);
+#endif
     DEBUG_L(STMT_START {
                 dSAVE_ERRNO;
                 PerlIO_printf(Perl_debug_log, "%s:%d: %s\n", __FILE__, __LINE__,
@@ -2162,7 +2217,11 @@ S_win32_setlocale(pTHX_ int category, const char* locale)
     for (i = 0; i < LC_ALL_INDEX; i++) {
         result = PerlEnv_getenv(category_names[i]);
         if (result && strNE(result, "")) {
+#ifdef USE_WSETLOCALE
+            S_wrap_wsetlocale(aTHX_ categories[i], locale);
+#else
             setlocale(categories[i], result);
+#endif
             DEBUG_Lv(PerlIO_printf(Perl_debug_log, "%s:%d: %s\n",
                 __FILE__, __LINE__,
                 setlocale_debug_string(categories[i], result, "not captured")));
-- 
2.20.1.windows.1

@p5pRT
Copy link
Author

p5pRT commented Aug 15, 2019

From @steve-m-hay

On Mon, 12 Aug 2019 22​:49​:19 -0700, tonyc wrote​:

On Sat, 10 Aug 2019 05​:53​:14 -0700, shay wrote​:

The patch looks good to me, except that the second

S_wrap_wsetlocale(aTHX_ category, locale);

looks like it should be

S_wrap_wsetlocale(aTHX_ categories[i], result);

?

Updated patch attached.

You've changed category to categories[i], but not locale to result.

@p5pRT
Copy link
Author

p5pRT commented Aug 18, 2019

From @steve-m-hay

On Thu, 15 Aug 2019 at 08​:05, Steve Hay via RT
<perlbug-followup@​perl.org> wrote​:

On Mon, 12 Aug 2019 22​:49​:19 -0700, tonyc wrote​:

On Sat, 10 Aug 2019 05​:53​:14 -0700, shay wrote​:

The patch looks good to me, except that the second

S_wrap_wsetlocale(aTHX_ category, locale);

looks like it should be

S_wrap_wsetlocale(aTHX_ categories[i], result);

?

Updated patch attached.

You've changed category to categories[i], but not locale to result.

I've retested the updated patch with that extra change that you missed
too, and it is still passing all tests.

@p5pRT
Copy link
Author

p5pRT commented Sep 3, 2019

From @tonycoz

On Sun, 18 Aug 2019 04​:04​:52 -0700, shay wrote​:

On Thu, 15 Aug 2019 at 08​:05, Steve Hay via RT
<perlbug-followup@​perl.org> wrote​:

On Mon, 12 Aug 2019 22​:49​:19 -0700, tonyc wrote​:

On Sat, 10 Aug 2019 05​:53​:14 -0700, shay wrote​:

The patch looks good to me, except that the second

S_wrap_wsetlocale(aTHX_ category, locale);

looks like it should be

S_wrap_wsetlocale(aTHX_ categories[i], result);

?

Updated patch attached.

You've changed category to categories[i], but not locale to result.

I've retested the updated patch with that extra change that you missed
too, and it is still passing all tests.

Thanks, I've applied it with that other fix and a shiny commit message
as 6c33203.

Tony

@p5pRT
Copy link
Author

p5pRT commented Sep 3, 2019

@tonycoz - Status changed from 'open' to 'pending release'

@p5pRT
Copy link
Author

p5pRT commented Sep 3, 2019

From @steve-m-hay

On Mon, 02 Sep 2019 18​:03​:28 -0700, tonyc wrote​:

On Sun, 18 Aug 2019 04​:04​:52 -0700, shay wrote​:

On Thu, 15 Aug 2019 at 08​:05, Steve Hay via RT
<perlbug-followup@​perl.org> wrote​:

On Mon, 12 Aug 2019 22​:49​:19 -0700, tonyc wrote​:

On Sat, 10 Aug 2019 05​:53​:14 -0700, shay wrote​:

The patch looks good to me, except that the second

S_wrap_wsetlocale(aTHX_ category, locale);

looks like it should be

S_wrap_wsetlocale(aTHX_ categories[i], result);

?

Updated patch attached.

You've changed category to categories[i], but not locale to result.

I've retested the updated patch with that extra change that you missed
too, and it is still passing all tests.

Thanks, I've applied it with that other fix and a shiny commit message
as 6c33203.

Your commit isn't quite what I was expecting. When I noted previously that "You've changed category to categories[i], but not locale to result" I meant that the second S_wrap_wsetlocale() call should be S_wrap_wsetlocale(aTHX_ categories[i], result) -- to match the arguments of the existing second setlocale() call, which was setlocale(categories[i], result).

Instead, you've left that S_wrap_wsetlocale() as S_wrap_wsetlocale(aTHX_ categories[i], locale) and changed the existing setlocale() call to setlocale(categories[i], locale). Did you mean to do that?

I've belatedly reproduced the failure in a small test program​:

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

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

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

This prints​:

9​: Japanese_Japan.932

and then causes an invalid parameter exception to be raised. There is no invalid parameter handler in this program to deal with it, so the program crashes​:

test.exe!_invoke_watson(const wchar_t * expression, const wchar_t * function_name, const wchar_t * file_name, unsigned int line_number, unsigned __int64 reserved) Line 224 C++
  test.exe!_invalid_parameter(const wchar_t * const expression, const wchar_t * const function_name, const wchar_t * const file_name, const unsigned int line_number, const unsigned __int64 reserved) Line 112 C++
  test.exe!_invalid_parameter_noinfo() Line 118 C++
  test.exe!_mbstowcs_s_l(unsigned __int64 * pConvertedChars, wchar_t * pwcs, unsigned __int64 sizeInWords, const char * s, unsigned __int64 n, __crt_locale_pointers * plocinfo) Line 246 C++
  test.exe!mbstowcs_s(unsigned __int64 * pConvertedChars, wchar_t * pwcs, unsigned __int64 sizeInWords, const char * s, unsigned __int64 n) Line 315 C++
  [Inline Frame] test.exe!call_wsetlocale(const int category, const char * const narrow_locale) C++
  test.exe!setlocale​::__l2​::<lambda>() Line 41 C++
  test.exe!__crt_seh_guarded_call<char *>​::operator()<void <lambda>(void),char * <lambda>(void) &,void <lambda>(void) >(__acrt_lock_and_call​::__l2​::void <lambda>(void) && setup, setlocale​::__l2​::char * <lambda>(void) & action, __acrt_lock_and_call​::__l2​::void <lambda>(void) && cleanup) Line 204 C++
  [Inline Frame] test.exe!__acrt_lock_and_call(const __acrt_lock_id) C++
  test.exe!setlocale(int _category, const char * _locale) Line 119 C++
  test.exe!main() Line 11 C++

I don't think it's a(nother) CRT bug. It's just garbage-in garbage-out​: We have successfully switched to Japanese locale and then use six bytes ("Català") that aren't a valid Japanese encoding, so the CRT is correct to complain it's an invalid parameter.

The fix is to deal with the encoding correctly so as not to pass garbage in, which is hopefully what your patch takes care of.

@p5pRT
Copy link
Author

p5pRT commented Sep 5, 2019

From @tonycoz

On Tue, 03 Sep 2019 00​:48​:47 -0700, shay wrote​:

On Mon, 02 Sep 2019 18​:03​:28 -0700, tonyc wrote​:

On Sun, 18 Aug 2019 04​:04​:52 -0700, shay wrote​:

On Thu, 15 Aug 2019 at 08​:05, Steve Hay via RT
<perlbug-followup@​perl.org> wrote​:

On Mon, 12 Aug 2019 22​:49​:19 -0700, tonyc wrote​:

On Sat, 10 Aug 2019 05​:53​:14 -0700, shay wrote​:

The patch looks good to me, except that the second

S_wrap_wsetlocale(aTHX_ category, locale);

looks like it should be

S_wrap_wsetlocale(aTHX_ categories[i], result);

?

Updated patch attached.

You've changed category to categories[i], but not locale to
result.

I've retested the updated patch with that extra change that you
missed
too, and it is still passing all tests.

Thanks, I've applied it with that other fix and a shiny commit
message
as 6c33203.

Your commit isn't quite what I was expecting. When I noted previously
that "You've changed category to categories[i], but not locale to
result" I meant that the second S_wrap_wsetlocale() call should be
S_wrap_wsetlocale(aTHX_ categories[i], result) -- to match the
arguments of the existing second setlocale() call, which was
setlocale(categories[i], result).

Instead, you've left that S_wrap_wsetlocale() as
S_wrap_wsetlocale(aTHX_ categories[i], locale) and changed the
existing setlocale() call to setlocale(categories[i], locale). Did you
mean to do that?

Yeah, it was a dumb mistake on my part.

The attached should fix it.

Tony

@p5pRT
Copy link
Author

p5pRT commented Sep 5, 2019

From @tonycoz

0001-perl-133981-fix-my-stupid-mistake.patch
From 17a1e9ac2917a0f8cdb3bf899724e07190e3d8ec Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Thu, 5 Sep 2019 15:37:30 +1000
Subject: (perl #133981) fix my stupid mistake

---
 locale.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/locale.c b/locale.c
index 0029c8023a..cdf125cee5 100644
--- a/locale.c
+++ b/locale.c
@@ -2218,9 +2218,9 @@ S_win32_setlocale(pTHX_ int category, const char* locale)
         result = PerlEnv_getenv(category_names[i]);
         if (result && strNE(result, "")) {
 #ifdef USE_WSETLOCALE
-            S_wrap_wsetlocale(aTHX_ categories[i], locale);
+            S_wrap_wsetlocale(aTHX_ categories[i], result);
 #else
-            setlocale(categories[i], locale);
+            setlocale(categories[i], result);
 #endif
             DEBUG_Lv(PerlIO_printf(Perl_debug_log, "%s:%d: %s\n",
                 __FILE__, __LINE__,
-- 
2.23.0.windows.1

@p5pRT
Copy link
Author

p5pRT commented Sep 5, 2019

@tonycoz - Status changed from 'pending release' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Sep 6, 2019

From @steve-m-hay

On Wed, 04 Sep 2019 22​:39​:51 -0700, tonyc wrote​:

On Tue, 03 Sep 2019 00​:48​:47 -0700, shay wrote​:

On Mon, 02 Sep 2019 18​:03​:28 -0700, tonyc wrote​:

On Sun, 18 Aug 2019 04​:04​:52 -0700, shay wrote​:

On Thu, 15 Aug 2019 at 08​:05, Steve Hay via RT
<perlbug-followup@​perl.org> wrote​:

On Mon, 12 Aug 2019 22​:49​:19 -0700, tonyc wrote​:

On Sat, 10 Aug 2019 05​:53​:14 -0700, shay wrote​:

The patch looks good to me, except that the second

S_wrap_wsetlocale(aTHX_ category, locale);

looks like it should be

S_wrap_wsetlocale(aTHX_ categories[i], result);

?

Updated patch attached.

You've changed category to categories[i], but not locale to
result.

I've retested the updated patch with that extra change that you
missed
too, and it is still passing all tests.

Thanks, I've applied it with that other fix and a shiny commit
message
as 6c33203.

Your commit isn't quite what I was expecting. When I noted previously
that "You've changed category to categories[i], but not locale to
result" I meant that the second S_wrap_wsetlocale() call should be
S_wrap_wsetlocale(aTHX_ categories[i], result) -- to match the
arguments of the existing second setlocale() call, which was
setlocale(categories[i], result).

Instead, you've left that S_wrap_wsetlocale() as
S_wrap_wsetlocale(aTHX_ categories[i], locale) and changed the
existing setlocale() call to setlocale(categories[i], locale). Did you
mean to do that?

Yeah, it was a dumb mistake on my part.

The attached should fix it.

Yes, that looks good now.

@p5pRT
Copy link
Author

p5pRT commented Sep 8, 2019

From @tonycoz

On Fri, 06 Sep 2019 00​:02​:05 -0700, shay wrote​:

On Wed, 04 Sep 2019 22​:39​:51 -0700, tonyc wrote​:

On Tue, 03 Sep 2019 00​:48​:47 -0700, shay wrote​:

On Mon, 02 Sep 2019 18​:03​:28 -0700, tonyc wrote​:

On Sun, 18 Aug 2019 04​:04​:52 -0700, shay wrote​:

On Thu, 15 Aug 2019 at 08​:05, Steve Hay via RT
<perlbug-followup@​perl.org> wrote​:

On Mon, 12 Aug 2019 22​:49​:19 -0700, tonyc wrote​:

On Sat, 10 Aug 2019 05​:53​:14 -0700, shay wrote​:

The patch looks good to me, except that the second

S_wrap_wsetlocale(aTHX_ category, locale);

looks like it should be

S_wrap_wsetlocale(aTHX_ categories[i], result);

?

Updated patch attached.

You've changed category to categories[i], but not locale to
result.

I've retested the updated patch with that extra change that you
missed
too, and it is still passing all tests.

Thanks, I've applied it with that other fix and a shiny commit
message
as 6c33203.

Your commit isn't quite what I was expecting. When I noted previously
that "You've changed category to categories[i], but not locale to
result" I meant that the second S_wrap_wsetlocale() call should be
S_wrap_wsetlocale(aTHX_ categories[i], result) -- to match the
arguments of the existing second setlocale() call, which was
setlocale(categories[i], result).

Instead, you've left that S_wrap_wsetlocale() as
S_wrap_wsetlocale(aTHX_ categories[i], locale) and changed the
existing setlocale() call to setlocale(categories[i], locale). Did you
mean to do that?

Yeah, it was a dumb mistake on my part.

The attached should fix it.

Yes, that looks good now.

Applied as 17a1e9a.

Sorry about the mess.

Tony

@p5pRT
Copy link
Author

p5pRT commented Sep 8, 2019

@tonycoz - Status changed from 'open' to 'pending release'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant