From tbauer@tibco.com

I have a PERL application server using Sockets. The application works on UNIX PERL, and also works on Windows when using Strawberry 5.10. However when it runs on Strawberry 5.16, PERL crashes and I receive a Windows exception report (attached).

I have tried the 32 bit and 64 bit versions and receive the same error. Any idea what is happening?

Thanks
Tom

From tbauer@tibco.com

Report.wer

From @Leont

On Wed, Nov 28, 2012 at 12​:04 AM, Tom Bauer <perlbug-followup@​perl.org> wrote​:

I have a PERL application server using Sockets. The application works on UNIX PERL, and also works on Windows when using Strawberry 5.10. However when it runs on Strawberry 5.16, PERL crashes and I receive a Windows exception report (attached).

The report doesn't say much. Can you send a script that shows this
behavior (preferably as short as possible, it's hard to analyze a 10K
line program for crashes). Or otherwise would you be able to give a
stacktrace?

Leon

P.S. The text of your email shows up weirdly, both in gmail and the
archive (http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2012-11/msg01081.html).
Judging by the HTML it seems like you're sending email with MS Word,
maybe you should consider a proper email client. In particular, the
perlbug is preferred for filing bugs, as it will include various
pieces of information on your local configuration.

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

From @nwc10

On Fri, Nov 30, 2012 at 02​:44​:44PM +0000, Tom Bauer wrote​:

Hi Leon

I am re-sending this in text mode in case HTML mode was causing problems.
Attached is a zip file that contains the mini-dump.  Hopefully this will have the information that you need to look at this.  Unfortunately the application that is crashing is a server side application.  I cannot find a way to narrow down the cause of the failure. 

I doubt that anyone active on the mailing list that deals with bug reports
can process whatever a "mini-dump" is. I don't even recognise the format,
let alone have any tools to deal with one. (I'm not using Windows)

Leon asked for a stack trace. Are you able to generate a textual stack trace?

If this does not help, I can probably find a way to ship you the application that can reproduce the issue.

A small script that reproduces the issue is most useful. The more platform
dependant modules it needs, the lower the chance of anyone being able to
replicate it.

Nicholas Clark

From @jandubois

On Tue, Dec 11, 2012 at 7​:02 AM, Nicholas Clark <nick@​ccl4.org> wrote​:

On Fri, Nov 30, 2012 at 02​:44​:44PM +0000, Tom Bauer wrote​:

Hi Leon

I am re-sending this in text mode in case HTML mode was causing problems.
Attached is a zip file that contains the mini-dump. Hopefully this will have the information that you need to look at this. Unfortunately the application that is crashing is a server side application. I cannot find a way to narrow down the cause of the failure.

I doubt that anyone active on the mailing list that deals with bug reports
can process whatever a "mini-dump" is. I don't even recognise the format,
let alone have any tools to deal with one. (I'm not using Windows)

A mini-dump is a severy stripped down core file for Windows. It is
really only useful for device driver bugs as it doesn't contain the
user-mode call stack.

Leon asked for a stack trace. Are you able to generate a textual stack trace?

I think I can see the crashing instruction​:

perl516+1090d6
713c90d6 c7050000000000000000 mov dword ptr ds​:[0],0

I strongly suspect that this is the "free to wrong pool" error in win32/vmem.h​:

  int *nowhere = NULL;
  Perl_warn(aTHX_ "Free to wrong pool %p not %p",this,ptr->owner);
  *nowhere = 0; /* this segfault is deliberate,

I can see the list of loaded modules, but don't see any threading
related (or incompatible) XS modules that may be obvious suspects, so
I have no idea why that may have triggered.

If this does not help, I can probably find a way to ship you the application that can reproduce the issue.

I would also try to use the win32-vanilla@​perl.org mailing list; the
people who build StrawberryPerl hang out there and may be able to
suggest additional debugging options.

Cheers,
-Jan

From @bulk88

Since Tom Bauer's 2nd post never made it onto RT for some reason I will
paste it in and post PerlDump.zip.

Tom Bauer wrote​:

Hi Leon

I am re-sending this in text mode in case HTML mode was causing problems.
Attached is a zip file that contains the mini-dump. Hopefully this
will have the information that you need to look at this. Unfortunately
the application that is crashing is a server side application. I cannot
find a way to narrow down the cause of the failure.

If this does not help, I can probably find a way to ship you the
application that can reproduce the issue.

Thanks
Tom

PERL Version info
c​:\strawberry516\perl\bin\perl -v

This is perl 5, version 16, subversion 2 (v5.16.2) built for
MSWin32-x86-multi-thread

Copyright 1987-2012, Larry Wall

Perl may be copied only under the terms of either the Artistic License
or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl". If you have access to the
Internet, point your browser at http​://www.perl.org/, the Perl Home Page.

--
bulk88 ~ bulk88 at hotmail.com

From @bulk88

PerlDump.zip

From @bulk88

On Tue Dec 11 10​:03​:52 2012, jdb wrote​:

Leon asked for a stack trace. Are you able to generate a textual
stack trace?

I think I can see the crashing instruction​:

perl516+1090d6
713c90d6 c7050000000000000000 mov dword ptr ds​:[0],0

I strongly suspect that this is the "free to wrong pool" error in
win32/vmem.h​:

        int \*nowhere = NULL;
        Perl\_warn\(aTHX\_ "Free to wrong pool %p not %p"\,this\,ptr\->owner\);
            \*nowhere = 0; /\* this segfault is deliberate\,

I can see the list of loaded modules, but don't see any threading
related (or incompatible) XS modules that may be obvious suspects, so
I have no idea why that may have triggered.

Correct.

In 32 bit strawberry perl 5.16.1 (I dont have a 5.16.2 that is used by
the reporter), VMem​::Free is
__________________________________________________________________
713C8F70 83 EC 1C sub esp,1Ch
713C8F73 89 5C 24 10 mov dword ptr [esp+10h],ebx
713C8F77 8B 5C 24 24 mov ebx,dword ptr [esp+24h]
713C8F7B 89 74 24 14 mov dword ptr [esp+14h],esi
713C8F7F 8B 74 24 20 mov esi,dword ptr [esp+20h]
713C8F83 89 7C 24 18 mov dword ptr [esp+18h],edi
713C8F87 85 DB test ebx,ebx
713C8F89 74 35 je 713C8FC0
713C8F8B 8B 7B FC mov edi,dword ptr [ebx-4]
713C8F8E 39 F7 cmp edi,esi
713C8F90 74 3E je 713C8FD0
713C8F92 85 FF test edi,edi
713C8F94 74 2A je 713C8FC0
713C8F96 E8 95 33 01 00 call 713DC330
713C8F9B 8B 53 FC mov edx,dword ptr [ebx-4]
713C8F9E 89 74 24 08 mov dword ptr [esp+8],esi
713C8FA2 C7 44 24 04 B8 5E 40 71 mov dword ptr [esp+4],71405EB8h
713C8FAA 89 54 24 0C mov dword ptr [esp+0Ch],edx
713C8FAE 89 04 24 mov dword ptr [esp],eax
713C8FB1 E8 6A 8F FF FF call 713C1F20
713C8FB6 C7 05 00 00 00 00 00 00 00 00 mov dword ptr ds​:[0],0
713C8FC0 8B 5C 24 10 mov ebx,dword ptr [esp+10h]
713C8FC4 8B 74 24 14 mov esi,dword ptr [esp+14h]
713C8FC8 8B 7C 24 18 mov edi,dword ptr [esp+18h]
713C8FCC 83 C4 1C add esp,1Ch
713C8FCF C3 ret
_____________________________________________________________________
in the dump file provided I see
_____________________________________________________________________
713C9090 83 EC 1C sub esp,1Ch
713C9093 89 5C 24 10 mov dword ptr [esp+10h],ebx
713C9097 8B 5C 24 24 mov ebx,dword ptr [esp+24h]
713C909B 89 74 24 14 mov dword ptr [esp+14h],esi
713C909F 8B 74 24 20 mov esi,dword ptr [esp+20h]
713C90A3 89 7C 24 18 mov dword ptr [esp+18h],edi
713C90A7 85 DB test ebx,ebx
713C90A9 74 35 je 713C90E0
713C90AB 8B 7B FC mov edi,dword ptr [ebx-4]
713C90AE 39 F7 cmp edi,esi
713C90B0 74 3E je 713C90F0
713C90B2 85 FF test edi,edi
713C90B4 74 2A je 713C90E0
713C90B6 E8 95 33 01 00 call 713DC450
713C90BB 8B 53 FC mov edx,dword ptr [ebx-4]
713C90BE 89 74 24 08 mov dword ptr [esp+8],esi
713C90C2 C7 44 24 04 B8 5E 40 71 mov dword ptr [esp+4],71405EB8h
713C90CA 89 54 24 0C mov dword ptr [esp+0Ch],edx
713C90CE 89 04 24 mov dword ptr [esp],eax
713C90D1 E8 4A 8F FF FF call 713C2020
713C90D6 C7 05 00 00 00 00 00 00 00 00 mov dword ptr ds​:[0],0
713C90E0 8B 5C 24 10 mov ebx,dword ptr [esp+10h]
713C90E4 8B 74 24 14 mov esi,dword ptr [esp+14h]
713C90E8 8B 7C 24 18 mov edi,dword ptr [esp+18h]
713C90EC 83 C4 1C add esp,1Ch
713C90EF C3 ret
_________________________________________________________________

Poor to no C debugging ability, is one of the reasons to not use
Strawberry Perl. GDB has many problems on windows in my personal
experience. No GUI, CL only, and .org w64 mingw fork problems, and if
the GDB isn't the one that compiled the perl image, erratic behavior or
GDB freezes. Last I checked strawberry does not include GDB. I don't
remember if GDB can use MS PDBs for MS DLL callstacks or not so
callstacks could be useless if a MS DLL was no frame pointer optimized
and it crashed.

To the OP, this might be a Perl the interpreter problem or an XS
problem. Its unknown unless someone else other than you can replicate,
or you provide a callstack of the crash. ActivePerl had a PDB symbol
file addon, (look for the "-symbols.zip" files). Extract the symbols
zip so each PDB file is in the same folder as the dll it shares its name
with. Then run the process with WinDbg (free) or Visual Studio (maybe
free/shareware by now, IDK, I have an old paid version) debuggers. When
the perl process crashes (and pauses and the debugger takes over
control), your callstack will be available going from VMem​::Free going
back aslong as the debugger found the pdb files (slightly complicated,
enough writing for now for me).

--
bulk88 ~ bulk88 at hotmail.com

From @robschaber

First time using this bug tracker, forgive me if I've sent this to the
wrong place. I think I am also having this issue. Here is my test script​:

use threads;
use HTTP​::Tiny;
my @​thr = map { threads->create( sub {
  my $http = HTTP​::Tiny->new( timeout => 1 );
  while (1) {
  my $res = $http->get('http​://127.0.0.1/');
  print $res->{status}, "\n";
  }
} ) } 1 .. 100;
$_->join() for @​thr;

On my machine (Windows 7 x64, version 6.1.7601), this crashes within a
few seconds on​:

ActivePerl 5.16.1.1601 (x64 and x86)
Strawberry 5.16.1.1 (x86)
ActivePerl 5.14.2.1402 (x64)
ActivePerl 5.12.4.1204 (x64)
ActivePerl 5.16.1.1601 (x86) on WinXP SP3 virtual machine

...and runs indefinitely on​:

Strawberry 5.12.3.0 (x64)
Strawberry 5.10.1.5 (x86)
Perl 5.14.2 on a Ubuntu 12.10 virtual machine

Decreasing the number of threads or increasing the length of the timeout
only seems to delay the crash. I've also replaced HTTP​::Tiny with
LWP​::UserAgent with similar (worse) results.

I tried to follow bulk88's suggestions in this thread regarding
debugging info, and used Visual Studio 2010's just-in-time debugger with
the .pdb files from ActiveState to get the following​:

====================================================================

EXCEPTION​:

First-chance exception at 0x774512f7 in perl.exe​: 0xC0000008​: An invalid
handle was specified.

====================================================================

CALL STACK​:

ntdll.dll!00000000774512f7()
  [Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
  KernelBase.dll!000007fefd441873()
  kernel32.dll!0000000077302f51()
  msvcrt.dll!000007fefd947c27()
  msvcrt.dll!000007fefd947bac()
  perl516.dll!PerlLIOClose(IPerlLIO * piPerl=0x000000001378fa50, int
handle=0) Line 948 + 0x27 bytes C
  perl516.dll!PerlIOUnix_close(interpreter * my_perl=0x000000001323ffd8,
_PerlIO * * f=0x0000000012f945c8) Line 2871 + 0xf bytes C
  perl516.dll!PerlIOBuf_close(interpreter * my_perl=0x0000000000000001,
_PerlIO * * f=0x00000000133b5eb8) Line 4235 + 0x85 bytes C
  perl516.dll!Perl_PerlIO_close(interpreter *
my_perl=0x0000000000000000, _PerlIO * * f=0x00000000133b5eb8) Line 1487
+ 0x3c bytes C
  perl516.dll!Perl_io_close(interpreter * my_perl=0x0000000011718998, io
* io=0x00000000122481b8, char not_implicit='¸') Line 980 C
  perl516.dll!Perl_pp_close(interpreter * my_perl=0x0000000011718998)
Line 654 + 0xe bytes C
  perl516.dll!Perl_runops_standard(interpreter *
my_perl=0x0000000011718998) Line 41 + 0x6 bytes C
  perl516.dll!Perl_call_sv(interpreter * my_perl=0x0000000011718998, sv
* sv=0x00000000133b5e88, volatile long flags=11) Line 2707 C
  threads.dll!S_ithread_run(void * arg=0x0000000000000000) Line 517 +
0x15 bytes C
  kernel32.dll!00000000772f652d()
  ntdll.dll!000000007742c521()

====================================================================

DISASSEMBLY​:

0000000077451001 add dword ptr [rax+66000000h],896F0F44h
000000007745100B nop
000000007745100C add byte ptr [rax],al
000000007745100E add byte ptr [rsi+44h],ah
0000000077451011 movq mm2,mmword ptr [rcx+0A0h]
0000000077451018 movdqa xmm11,xmmword ptr [rcx+0B0h]
0000000077451021 movdqa xmm12,xmmword ptr [rcx+0C0h]
000000007745102A movdqa xmm13,xmmword ptr [rcx+0D0h]
0000000077451033 movdqa xmm14,xmmword ptr [rcx+0E0h]
000000007745103C movdqa xmm15,xmmword ptr [rcx+0F0h]
0000000077451045 mov rdx,qword ptr [rcx+50h]
0000000077451049 mov rbp,qword ptr [rcx+18h]
000000007745104D mov rsp,qword ptr [rcx+10h]
0000000077451051 jmp rdx
0000000077451053 mov dword ptr [rsp+30h],80000026h
000000007745105B mov dword ptr [rsp+34h],r10d
0000000077451060 mov qword ptr [rsp+38h],r10
0000000077451065 mov qword ptr [rsp+40h],r10
000000007745106A mov qword ptr [rsp+28h],r10
000000007745106F inc r10d
0000000077451072 mov dword ptr [rsp+48h],r10d
0000000077451077 mov qword ptr [rsp+50h],rcx
000000007745107C lea rax,[rsp+60h]
0000000077451081 mov qword ptr [rsp+20h],rax
0000000077451086 mov r9,rdx
0000000077451089 lea r8,[rsp+30h]
000000007745108E mov rdx,qword ptr [rcx+50h]
0000000077451092 mov rcx,qword ptr [rcx]
0000000077451095 call 00000000774185F0
000000007745109A jmp 0000000077451053
000000007745109C nop
000000007745109D nop
000000007745109E nop
000000007745109F nop
00000000774510A0 nop
00000000774510A1 nop
00000000774510A2 nop
00000000774510A3 nop
00000000774510A4 nop
00000000774510A5 nop
00000000774510A6 nop
00000000774510A7 nop
00000000774510A8 nop
00000000774510A9 nop
00000000774510AA nop
00000000774510AB nop
00000000774510AC nop
00000000774510AD nop
00000000774510AE nop
00000000774510AF nop
00000000774510B0 nop
00000000774510B1 nop
00000000774510B2 nop
00000000774510B3 nop
00000000774510B4 nop
00000000774510B5 nop
00000000774510B6 nop
00000000774510B7 nop
00000000774510B8 nop
00000000774510B9 nop
00000000774510BA nop
00000000774510BB nop
00000000774510BC nop
00000000774510BD nop
00000000774510BE nop
00000000774510BF nop
00000000774510C0 int 3
00000000774510C1 int 3
00000000774510C2 int 3
00000000774510C3 int 3
00000000774510C4 int 3
00000000774510C5 int 3
00000000774510C6 nop word ptr [rax+rax]
00000000774510D0 sub rsp,28h
00000000774510D4 test dword ptr [rcx+4],66h
00000000774510DB je 00000000774510E2
00000000774510DD call 0000000077452B20
00000000774510E2 mov eax,1
00000000774510E7 add rsp,28h
00000000774510EB ret
00000000774510EC int 3
00000000774510ED int 3
00000000774510EE int 3
00000000774510EF int 3
00000000774510F0 int 3
00000000774510F1 int 3
00000000774510F2 nop word ptr [rax+rax]
0000000077451100 mov rcx,qword ptr [rsp+18h]
0000000077451105 mov rax,rcx
0000000077451108 mov r9,rsp
000000007745110B sar rcx,2
000000007745110F mov rdx,qword ptr [rsp+8]
0000000077451114 neg rcx
0000000077451117 mov r8,qword ptr [rsp+10h]
000000007745111C shld rcx,rcx,20h
0000000077451121 test ecx,ecx
0000000077451123 je 0000000077451147
0000000077451125 mov rcx,qword ptr [rsp]
0000000077451129 call rax
000000007745112B mov rcx,rsp
000000007745112E mov dl,1
0000000077451130 call 0000000077451740
0000000077451135 test eax,eax
0000000077451137 je 0000000077451100
0000000077451139 mov esi,eax
000000007745113B mov ecx,esi
000000007745113D call 00000000774CD7C0
0000000077451142 nop
0000000077451143 jmp 0000000077451145
0000000077451145 jmp 000000007745113E
0000000077451147 mov eax,dword ptr [rsp]
000000007745114A or rcx,rax
000000007745114D mov rax,qword ptr [7753A8D8h]
0000000077451154 test rax,rax
0000000077451157 je 000000007745112B
0000000077451159 call rax
000000007745115B mov esi,0C000000Dh
0000000077451160 jmp 000000007745113B
0000000077451162 int 3
0000000077451163 int 3
0000000077451164 int 3
0000000077451165 int 3
0000000077451166 int 3
0000000077451167 int 3
0000000077451168 nop word ptr [rax+rax]
0000000077451173 sub rsp,38h
0000000077451177 mov rax,qword ptr gs​:[60h]
0000000077451180 mov r9,qword ptr [rax+20h]
0000000077451184 test byte ptr [r9+0Ah],8
0000000077451189 jne 000000007745119A
000000007745118B mov rdx,r8
000000007745118E call 00000000774E6890
0000000077451193 mov eax,0
0000000077451198 jmp 00000000774511E3
000000007745119A test byte ptr [rcx+4],66h
000000007745119E jne 00000000774511D8
00000000774511A0 mov qword ptr [rsp+28h],0
00000000774511A9 mov qword ptr [rsp+20h],r8
00000000774511AE mov r9d,dword ptr [rcx]
00000000774511B1 mov dword ptr [rsp+30h],r9d
00000000774511B6 mov r8,rcx
00000000774511B9 mov rcx,rdx
00000000774511BC lea rdx,[77451225h]
00000000774511C3 call 00000000774185F0
00000000774511C8 mov esi,dword ptr [rsp+30h]
00000000774511CC mov ecx,esi
00000000774511CE call 00000000774CD7C0
00000000774511D3 nop
00000000774511D4 jmp 00000000774511D6
00000000774511D6 jmp 00000000774511CF
00000000774511D8 test byte ptr [rcx+4],20h
00000000774511DC je 00000000774511E8
00000000774511DE mov eax,1
00000000774511E3 add rsp,38h
00000000774511E7 ret
00000000774511E8 mov r8d,dword ptr [rcx]
00000000774511EB xor ecx,ecx
00000000774511ED xor edx,edx
00000000774511EF call 0000000077451360
00000000774511F4 mov esi,eax
00000000774511F6 jmp 00000000774511CC
00000000774511F8 int 3
00000000774511F9 int 3
00000000774511FA int 3
00000000774511FB int 3
00000000774511FC int 3
00000000774511FD int 3
00000000774511FE nop dword ptr [rax+rax]
0000000077451206 mov rcx,qword ptr [rsp+20h]
000000007745120B mov edx,dword ptr [rsp+28h]
000000007745120F mov r8d,dword ptr [rsp+2Ch]
0000000077451214 mov rax,qword ptr gs​:[60h]
000000007745121D mov r9,qword ptr [rax+58h]
0000000077451221 call qword ptr [r9+r8*8]
0000000077451225 xor ecx,ecx
0000000077451227 xor edx,edx
0000000077451229 mov r8d,eax
000000007745122C call 0000000077451360
0000000077451231 mov esi,eax
0000000077451233 mov ecx,esi
0000000077451235 call 00000000774CD7C0
000000007745123A nop
000000007745123B jmp 000000007745123D
000000007745123D jmp 0000000077451236
000000007745123F nop
0000000077451240 int 3
0000000077451241 int 3
0000000077451242 int 3
0000000077451243 int 3
0000000077451244 int 3
0000000077451245 int 3
0000000077451246 nop dword ptr [rax]
000000007745124A cld
000000007745124B mov rax,qword ptr [7753A8E0h]
0000000077451252 test rax,rax
0000000077451255 je 0000000077451266
0000000077451257 mov rcx,rsp
000000007745125A add rcx,4F0h
0000000077451261 mov rdx,rsp
0000000077451264 call rax
0000000077451266 mov rcx,rsp
0000000077451269 add rcx,4F0h
0000000077451270 mov rdx,rsp
0000000077451273 call 0000000077418E20
0000000077451278 test al,al
000000007745127A je 0000000077451288
000000007745127C mov rcx,rsp
000000007745127F xor edx,edx
0000000077451281 call 000000007745093F
0000000077451286 jmp 000000007745129D
0000000077451288 mov rcx,rsp
000000007745128B add rcx,4F0h
0000000077451292 mov rdx,rsp
0000000077451295 xor r8b,r8b
0000000077451298 call 0000000077452630
000000007745129D mov ecx,eax
000000007745129F call 00000000774CD7C0
00000000774512A4 nop
00000000774512A5 jmp 00000000774512A7
00000000774512A7 nop
00000000774512A8 int 3
00000000774512A9 int 3
00000000774512AA int 3
00000000774512AB int 3
00000000774512AC int 3
00000000774512AD int 3
00000000774512AE nop word ptr [rax+rax]
00000000774512BD sub rsp,0C8h
00000000774512C4 mov dword ptr [rsp+0C0h],eax
00000000774512CB mov eax,dword ptr gs​:[2C0h]
00000000774512D3 lea rcx,[rsp+20h]
00000000774512D8 mov dword ptr [rcx],eax
00000000774512DA xor eax,eax
00000000774512DC mov dword ptr [rcx+4],eax
00000000774512DF mov qword ptr [rcx+8],rax
00000000774512E3 mov rdx,qword ptr [rsp+0C8h]
00000000774512EB mov qword ptr [rcx+10h],rdx
00000000774512EF mov dword ptr [rcx+18h],eax
00000000774512F2 call 0000000077419560
00000000774512F7 mov eax,dword ptr [rsp+0C0h]

====================================================================

C​:\Perl>perl -V
Summary of my perl5 (revision 5 version 16 subversion 1) configuration​:

  Platform​:
  osname=MSWin32, osvers=5.2, archname=MSWin32-x64-multi-thread
  uname=''
  config_args='undef'
  hint=recommended, useposix=true, d_sigaction=undef
  useithreads=define, usemultiplicity=define
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=define, use64bitall=undef, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cl', ccflags ='-nologo -GF -W3 -MD -Zi -DNDEBUG -Ox -GL
-fp​:precise -DWIN32 -D_CONSOLE -DNO_
STRICT -DWIN64 -DCONSERVATIVE -DPERL_TEXTMODE_SCRIPTS
-DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -D
PERL_IMPLICIT_SYS -DUSE_PERLIO',
  optimize='-MD -Zi -DNDEBUG -Ox -GL -fp​:precise',
  cppflags='-DWIN32'
  ccversion='16.0.40219', gccversion='', gccosandvers=''
  intsize=4, longsize=4, ptrsize=8, doublesize=8, byteorder=12345678
  d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8
  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=\lib
  libs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shel
l32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib
winmm.lib version.lib odbc
32.lib odbccp32.lib comctl32.lib msvcrt.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
  libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl516.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​:\Pe
rl\lib\CORE" -machine​:AMD64'

Characteristics of this binary (from libperl)​:
  Compile-time options​: HAS_TIMES HAVE_INTERP_INTERN MULTIPLICITY
  PERLIO_LAYERS PERL_DONT_CREATE_GVSV
  PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS
  PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PL_OP_SLAB_ALLOC
  USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
  USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE
  USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF
  USE_SITECUSTOMIZE
  Locally applied patches​:
  ActivePerl Build 1601 [296175]
  Built under MSWin32
  Compiled at Aug 30 2012 18​:41​:50
  %ENV​:
  PERL_CPANM_OPT="--verbose"
  PERL_JSON_BACKEND="JSON​::XS"
  PERL_YAML_BACKEND="YAML"
  @​INC​:
  C​:/Perl/site/lib
  C​:/Perl/lib
  .

====================================================================

Hopefully some of that is relevant. I don't really know my way around a
C debugger. If additional info is needed, I'm willing to try to get it,
with some coaching.

Thanks.

From @mnz2000

Hello!

I found this bug report because my Perl script keeps crashing
occasionally. I've had the crashes for years, but they are so infrequent
that I haven't gotten around to doing anything about them. Sometimes the
crashes occur once per week, sometimes several times per day. My script
is running 24/7.

I can confirm that rschaber's test script crashes on my machine with
ActiveState perl v5.14.2 and v5.16.3 on two different computers, both
running Windows 7.

Building perl 5.18.0 from source with Microsoft Visual Studio 2005 (full
version) creates an executable experiencing the same crash.

To fix​:

Comment out line 476 in win32/win32sck.c (ActiveState 5.16.3
AP1603_source) or line 476 in 5.18.0​:

err = closesocket(osf);
if (err == 0) {
// (void)close(fd); /* handle already closed, ignore error */
  return 0;
}

This fixes rschaber's test script on both 5.16.3 and 5.18.0. I haven't
tested this with my real-world script yet.

I have no idea if this is the right way to fix this, and if the
double-close is needed in certain scenarios. At least my fix should
confirm that the double-close may in fact cause problems.

To me, the biggest mystery regarding this bug is why Windows is
reporting 0xC0000008 (Invalid handle) as an exception. This exception
should be raised only when run under a debugger, or when some special
NtGlobalFlag is set. This isn't the case, and if it were, Perl should
crash in the very first close() call, not randomly.

Related report​: Perl crash when run under AppVerifier
(https://rt-archive.perl.org/perl5//Public/Bug/Display.html?id=118127)

Thanks to rschaber for creating a simple test script! It would have
taken ages to do the same from my script.

- Mikko

From @Leont

On Thu, Aug 8, 2013 at 7​:00 PM, Mikko Noromaa via RT
<perlbug-followup@​perl.org> wrote​:

Hello!

I found this bug report because my Perl script keeps crashing
occasionally. I've had the crashes for years, but they are so infrequent
that I haven't gotten around to doing anything about them. Sometimes the
crashes occur once per week, sometimes several times per day. My script
is running 24/7.

I can confirm that rschaber's test script crashes on my machine with
ActiveState perl v5.14.2 and v5.16.3 on two different computers, both
running Windows 7.

Building perl 5.18.0 from source with Microsoft Visual Studio 2005 (full
version) creates an executable experiencing the same crash.

To fix​:

Comment out line 476 in win32/win32sck.c (ActiveState 5.16.3
AP1603_source) or line 476 in 5.18.0​:

err = closesocket(osf);
if (err == 0) {
// (void)close(fd); /* handle already closed, ignore error */
return 0;
}

This fixes rschaber's test script on both 5.16.3 and 5.18.0. I haven't
tested this with my real-world script yet.

I have no idea if this is the right way to fix this, and if the
double-close is needed in certain scenarios. At least my fix should
confirm that the double-close may in fact cause problems.

To me, the biggest mystery regarding this bug is why Windows is
reporting 0xC0000008 (Invalid handle) as an exception. This exception
should be raised only when run under a debugger, or when some special
NtGlobalFlag is set. This isn't the case, and if it were, Perl should
crash in the very first close() call, not randomly.

Related report​: Perl crash when run under AppVerifier
(https://rt-archive.perl.org/perl5//Public/Bug/Display.html?id=118127)

Thanks to rschaber for creating a simple test script! It would have
taken ages to do the same from my script.

Given the use of threads that actually makes sense. There is a race
condition between the two closes. so if the handle gets reused you'll
run into an error.

Leon

From @bulk88

On Thu Aug 08 10​:00​:33 2013, mnoromaa wrote​:

Hello!

I found this bug report because my Perl script keeps crashing
occasionally. I've had the crashes for years, but they are so infrequent
that I haven't gotten around to doing anything about them. Sometimes the
crashes occur once per week, sometimes several times per day. My script
is running 24/7.

I was able to reproduce it effortlessly with a 32 bit perl on Server
2003 x64 using the test script in
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=115934#txn-1177892

This fixes rschaber's test script on both 5.16.3 and 5.18.0. I haven't
tested this with my real-world script yet.

I have no idea if this is the right way to fix this, and if the
double-close is needed in certain scenarios. At least my fix should
confirm that the double-close may in fact cause problems.

To me, the biggest mystery regarding this bug is why Windows is
reporting 0xC0000008 (Invalid handle) as an exception. This exception
should be raised only when run under a debugger, or when some special
NtGlobalFlag is set. This isn't the case, and if it were, Perl should
crash in the very first close() call, not randomly.

Yes, this is a big mystery. CloseHandle returns a bool with GLR error
codes. Throwing an exception without NtGlobalFlag is very strange. I get
the invalid handles without a C debugger, and with VS debugger.
Unchecking 0xc0000008 exception in VS's exception menu just disables the
ignore button, but doesn't stop the exceptions. I think something in the
nt kernel is blindly doing a RtlRaiseExeception and ignoring
NtGlobalFlags since I can't see the exception call in user mode. The
cheap hack fix is to put a SEH handler around C's close(), but have fun
doing that on GCC.

In one process run that I was NOT able to ever reproduce again in the
debugger but did reproduce when perl was run without the debugger
(0x7D64F08E is an int 3 instruction in the CS API) , a CS/mutex got
corrupted and the CS API was throwing exceptions in user mode. Later the
CS API started SEGVing.

I haven't run this on Win XP. And some tools I would use to further
research the NT kernel are on a different machine of mine which is down
right now. So I can't try to find what in kernel mode threw the
0xC0000008 and why. Based on the AppVerifier RT ticket, I'm starting to
think MS "improved" security at some point in the NT OS family. Or it is
a bug with VS debugger setting NtGlobalFlags when it shouldn't and the
real crash is the CS struct corruption.

Related report​: Perl crash when run under AppVerifier
(https://rt-archive.perl.org/perl5//Public/Bug/Display.html?id=118127)

Thanks to rschaber for creating a simple test script! It would have
taken ages to do the same from my script.

- Mikko

Attaching pics from my debugging session.

--
bulk88 ~ bulk88 at hotmail.com

From @bulk88

1.PNG

From @bulk88

4.PNG

From @bulk88

3.PNG

From @bulk88

7.PNG

From @bulk88

2.PNG

From @bulk88

6.PNG

From @bulk88

5.PNG

I'm pretty sure this is a duplicate of #12756 and #12979.