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

mingw breaks Perl_croak/Perl_die_unwind after minor and correct code changes #17521

Open
demerphq opened this issue Feb 2, 2020 · 1 comment

Comments

@demerphq
Copy link
Collaborator

demerphq commented Feb 2, 2020

Description
In several cases we have encountered mingw breakage related to Perl_croak/Perl_die_unwind after seemingly minor and clearly correct code changes. Two such issues are #17496 and #16729

There seem to be common patterns to this breakage, for instance DEBUGGING builds do not have the problem. All of the breakage stack reports include mention of Perl_die_unwind. There is some suggestion (in #16729) that this could be a linker error in the mingw compiler stack on windows.

In #17496 we applied a minor code change which triggers this bug in a totally unrelated test than is related to the code change. If we cannot find a solution for this then we may have to revert 2b30192 even though that would reintroduce a real bug experienced by all compilers.

This ticket is intended to consolidate such bug reports in one place so they can be addressed as a whole.

Thread 1 received signal ?, Unknown signal.
0x00007ff96c1dbf58 in ntdll!RtlRaiseStatus () from C:\Windows\SYSTEM32\ntdll.dll
(gdb) bt
#0  0x00007ff96c1dbf58 in ntdll!RtlRaiseStatus () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x00007ff96c18c911 in ntdll!memset () from C:\Windows\SYSTEM32\ntdll.dll
#2  0x00007ff96b8e324d in msvcrt!_setjmpex () from C:\Windows\System32\msvcrt.dll
#3  0x0000000062b12c11 in Perl_die_unwind (my_perl=0x0, my_perl@entry=0xd04fc8, msv=msv@entry=0x27abec8)
    at ..\pp_ctl.c:1824
#4  0x0000000062b98c1a in Perl_vcroak (my_perl=0xd04fc8, pat=<optimized out>, args=<optimized out>) at ..\util.c:1729
#5  0x0000000062b98cf6 in Perl_croak_nocontext (pat=0x62d39fe1 <these_details+2209> "%s") at ..\util.c:1763
#6  0x0000000062b992a7 in Perl_croak_no_modify () at ..\util.c:1792
#7  0x0000000062b8e98e in Perl_pp_sort (my_perl=0xd04fc8) at ..\pp_sort.c:895
#8  0x0000000062b8ea06 in Perl_runops_standard (my_perl=0xd04fc8) at ..\run.c:42
#9  0x0000000062b4e1e0 in S_run_body (oldscope=<optimized out>, my_perl=<optimized out>) at perl.c:2781
#10 perl_run (my_perl=0x62b9f310 <xs_init(PerlInterpreter*)>, my_perl@entry=0xd04fc8) at perl.c:2709
#11 0x0000000062ba29e8 in RunPerl (argc=<optimized out>, argv=<optimized out>, env=0xc02770) at perllib.c:213
#12 0x00000000004013c7 in __tmainCRTStartup ()
#13 0x00000000004014fb in mainCRTStartup ()
(gdb)

Steps to Reproduce
Compile Perl on the offending versions of mingw (8.10 is one version known to have this issue) and run tests, specifically t/op/sort.t
DEBUGGING mode is known to fix the problem so do not use that to investigate.

Expected behavior
No segfault.

Perl configuration
We have seen this break on the travis builds that are automatically generated for pushes to Perl5/perl. Eg:

https://github.com/Perl/perl5/runs/419405069?check_suite_focus=true

One of the reported affected configurations (From #16729) from the field is as follows:

Summary of my perl5 (revision 5 version 29 subversion 4) configuration​:

  Platform​:
  osname=MSWin32
  osvers=6.1.7601
  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='gcc'
  ccflags =' -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_SCRIPTS -D
PERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D__USE_MINGW_ANSI_STDIO
-fwrapv -fno-strict-aliasing -mms-bitfields'
  optimize='-s -O2'
  cppflags='-DWIN32'
  ccversion=''
  gccversion='8.1.0'
  gccosandvers=''
  intsize=4
  longsize=4
  ptrsize=8
  doublesize=8
  byteorder=12345678
  doublekind=3
  d_longlong=define
  longlongsize=8
  d_longdbl=define
  longdblsize=16
  longdblkind=3
  ivtype='long long'
  ivsize=8
  nvtype='double'
  nvsize=8
  Off_t='long long'
  lseeksize=8
  alignbytes=8
  prototype=define
  Linker and Libraries​:
  ld='g++'
  ldflags ='-s -L"C​:\_64\blead-5.29.4\lib\CORE" -L"C​:\_64\gcc-mingw-810\mingw6
4\lib"'
  libpth=C​:\_64\gcc-mingw-810\mingw64\lib C​:\_64\gcc-mingw-810\mingw64\x86_64-
w64-mingw32\lib C​:\_64\msys_810\1.0\local\lib C​:\_64\gcc-mingw-810\mingw64\lib\g
cc\x86_64-w64-mingw32\8.1.0
  libs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi3
2 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversio
n -lodbc32 -lodbccp32 -lcomctl32
  perllibs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladv
api32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lve
rsion -lodbc32 -lodbccp32 -lcomctl32
  libc=
  so=dll
  useshrplib=true
  libperl=libperl529.a
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_win32.xs
  dlext=dll
  d_dlsymun=undef
  ccdlflags=' '
  cccdlflags=' '
  lddlflags='-mdll -s -L"C​:\_64\blead-5.29.4\lib\CORE" -L"C​:\_64\gcc-mingw-810
\mingw64\lib"'

Characteristics of this binary (from libperl)​:
  Compile-time options​:
  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
  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
  Built under MSWin32
  Compiled at Oct 21 2018 19​:19​:23
  @​INC​:
  C​:/_64/blead-5.29.4/site/lib
  C​:/_64/blead-5.29.4/lib
@hvds
Copy link
Contributor

hvds commented Feb 2, 2020

Could it be a mutex issue? For some reason this reminds me of #17034 [perl #134172] - but we're not in Perl_sys_term() so it could be a total red herring.

Hugo

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

3 participants