Re: [perl #118127] Perl crash when run under AppVerifier

Hi,

Thanks for your reply. I don't think debugging flag is turned on at
customer site. Otherwise you will see this when analyzing the dump (
NTGLOBALFLAG:  0
APPLICATION_VERIFIER_FLAGS:  0 ). BTW, the job monitor code we use is
purely perl, so there is no confusion that non-perl code is causing the
crash here or throwing exception. Please find below the new crash report we
received. This seem to be coming win32's alarm implementation. Any thoughts
about this crash?

-Karthik

0:000> !analyze -v
*******************************************************************************
*
  *
*                        Exception Analysis
  *
*
  *
*******************************************************************************

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for
threads.dll -
GetPageUrlData failed, server returned HTTP status 404
URL requested:
http://watson.microsoft.com/StageOne/perl_exe/0_0_0_0/51a63046/ntdll_dll/6_1_7601_17725/4ec4aa8e/c0000008/000cd7d8.htm?Retriage=1

FAULTING_IP:
ntdll!RtlRaiseStatus+18
00000000`76e0d7d8 488b8424b8010000 mov     rax,qword ptr [rsp+1B8h]

EXCEPTION_RECORD:  ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000076e0d7d8 (ntdll!RtlRaiseStatus+0x0000000000000018)
   ExceptionCode: c0000008 (Invalid handle)
  ExceptionFlags: 00000001
NumberParameters: 0
Thread tried to close a handle that was invalid or illegal to close

DEFAULT_BUCKET_ID:  INVALID_POINTER_READ

PROCESS_NAME:  perl.exe

ERROR_CODE: (NTSTATUS) 0xc0000008 - An invalid HANDLE was specified.

EXCEPTION_CODE: (NTSTATUS) 0xc0000008 - An invalid HANDLE was specified.

MOD_LIST: <ANALYSIS/>

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

FAULTING_THREAD:  0000000000001554

PRIMARY_PROBLEM_CLASS:  INVALID_POINTER_READ

BUGCHECK_STR:  APPLICATION_FAULT_INVALID_POINTER_READ

LAST_CONTROL_TRANSFER:  from 0000000076da8e59 to 0000000076e0d7d8

STACK_TEXT:
00000000`0031de20 00000000`76da8e59 : 00000000`00000100 00000000`0031e670
00000000`00000000 00000000`0031e640 : ntdll!RtlRaiseStatus+0x18
00000000`0031e3c0 00000000`76d67e74 : 00000000`0031e600 00000000`00000000
00000000`c0150008 00000000`0031e600 : ntdll! ?? ::FNODOBFM::`string'+0x969e
00000000`0031e3f0 00000000`76d67b2e : 00000000`00000000 000007fe`fb9cbaf0
00000000`0031e690 000007fe`fd37d90d : ntdll!LdrpLoadDll+0x897
00000000`0031e600 000007fe`fd379aa9 : 00000000`00000000 00000000`00000000
000007fe`fb9cbaf0 00000000`00000062 : ntdll!LdrLoadDll+0x9a
00000000`0031e670 000007fe`fd37bc01 : 00000000`00000000 000007fe`fb9cbaf0
000007fe`fb9c5a10 00000000`00000000 : KERNELBASE!LoadLibraryExW+0x22e
00000000`0031e6e0 000007fe`fb98dffa : 00000000`00000000 00000065`00670061
00000000`00000000 00000000`00000000 : KERNELBASE!LoadLibraryExA+0x51
00000000`0031e730 000007fe`fb98dfb3 : 00000000`00000000 00000000`00000083
00000000`0049052a 00000000`00000001 : uxtheme!_delayLoadHelper2+0x96
00000000`0031e7c0 000007fe`fb98b192 : 00000000`0049052a 00000000`00010001
00000000`0031e860 00000000`00000004 : uxtheme!_tailMerge_dwmapi_dll+0x3f
00000000`0031e830 000007fe`fb9885a0 : 00000000`00000001 00000000`00000000
00000000`0049052a 00000000`00000083 : uxtheme!CThemeWnd::Reject+0x58
00000000`0031e860 000007fe`fb981607 : 00000000`00000000 00000000`00000083
00000000`00000000 00000000`0049052a : uxtheme!CThemeWnd::Attach+0x1cd
00000000`0031e8d0 000007fe`fb98b1c6 : 00000000`0031ec40 00000000`0049052a
00000000`00000000 00000000`0031ec40 : uxtheme!_ThemeDefWindowProc+0x133
00000000`0031e980 00000000`76c4aafc : 00000000`00000000 00000000`00000104
00000000`0031e9e8 00000000`0031e9f8 : uxtheme!ThemeDefWindowProcA+0xe
00000000`0031e9c0 00000000`6473b226 : 00000000`00000083 00000000`00000000
00000000`00000000 ffffffff`ffffffff : user32!DefWindowProcA+0xe6
00000000`0031ea10 00000000`76c59bd1 : 00000000`00000000 00000000`00000000
00000000`00000001 00000000`00000000 :
perl514!win32_message_window_proc+0x46
[c:\perl\x64\perl-5.14.2\win32\win32.c @ 4450]
00000000`0031ea40 00000000`76c572cb : 00000000`00000000 00000000`6473b1e0
00000000`00000000 00000000`00000000 : user32!UserCallWinProcCheckWow+0x1ad
00000000`0031eb00 00000000`76c506e8 : 00000000`76c5041a ffffffff`ffff0000
00000000`6473b1e0 00000000`0031ec58 : user32!DispatchClientMessage+0xc3
00000000`0031eb60 00000000`76d91225 : 00000000`00000000 fffff880`08baf790
00000000`00000000 00000000`00000000 : user32!_fnINOUTNCCALCSIZE+0x3c
00000000`0031ebc0 00000000`76c5041a : 00000000`76c50397 00000000`0031f088
00000000`00000000 00000000`0031f088 : ntdll!KiUserCallbackDispatcherContinue
00000000`0031ec58 00000000`76c50397 : 00000000`0031f088 00000000`00000000
00000000`0031f088 00000000`0031f088 : user32!ZwUserCreateWindowEx+0xa
00000000`0031ec60 00000000`76c505d8 : 00000000`0000002e 00000000`80000000
00000000`00000000 00000000`00000000 : user32!VerNtUserCreateWindowEx+0x27c
00000000`0031efd0 00000000`76c4a350 : 00000000`00000000 00000000`64870558
00000000`003da340 00000000`0000003c : user32!CreateWindowEx+0x404
00000000`0031f120 00000000`6473b657 : 00000000`0000000e 00000000`00683368
00000000`0000000e 00000000`6482bfbe : user32!CreateWindowExA+0x70
00000000`0031f1a0 00000000`6473b6af : 00000000`00000000 00000000`02a0b1d0
00000000`005955a8 00000000`647dd9d9 :
perl514!win32_create_message_window+0xa7
[c:\perl\x64\perl-5.14.2\win32\win32.c @ 4548]
00000000`0031f260 00000000`647bfd35 : 00000000`02a0b1d0 00000000`0363f910
00000000`003d33c8 00000000`00000001 : perl514!win32_alarm+0x3f
[c:\perl\x64\perl-5.14.2\win32\win32.c @ 2342]
00000000`0031f290 00000000`647942a6 : 00000000`005955a8 00000000`00000000
00000000`00000002 00000000`005955a8 : perl514!Perl_pp_alarm+0x55
[c:\perl\x64\perl-5.14.2\pp_sys.c @ 4565]
00000000`0031f2c0 00000000`64807991 : 00000000`00000001 00000000`6474cef0
00000000`003dc140 00000000`005955a8 : perl514!Perl_runops_standard+0x16
[c:\perl\x64\perl-5.14.2\run.c @ 41]
00000000`0031f2f0 00000000`64807c24 : 00000000`005955a8 00000000`00000000
00000000`0031f2d0 00000000`003da340 : perl514!S_run_body+0x131
[c:\perl\x64\perl-5.14.2\win32\perl.c @ 2352]
00000000`0031f320 00000000`6474d291 : 00000000`003d4620 00000000`003dc140
00000000`003da340 00000000`00000000 : perl514!perl_run+0x264
[c:\perl\x64\perl-5.14.2\win32\perl.c @ 2271]
00000000`0031f490 00000001`3f5811b2 : 00000000`00000001 00000000`00000000
00000000`00000000 00000000`00000000 : perl514!RunPerl+0x151
[c:\perl\x64\perl-5.14.2\win32\perllib.c @ 270]
00000000`0031f8d0 00000000`7667652d : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : perl!__tmainCRTStartup+0x11a
[f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crtexe.c @ 555]
00000000`0031f900 00000000`76d6c521 : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
00000000`0031f930 00000000`00000000 : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d


STACK_COMMAND:  ~0s; .ecxr ; kb

FOLLOWUP_IP:
uxtheme!_delayLoadHelper2+96
000007fe`fb98dffa 488bd8          mov     rbx,rax

SYMBOL_STACK_INDEX:  6

SYMBOL_NAME:  uxtheme!_delayLoadHelper2+96

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: uxtheme

IMAGE_NAME:  uxtheme.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5be093

FAILURE_BUCKET_ID:
 INVALID_POINTER_READ_c0000008_uxtheme.dll!_delayLoadHelper2

BUCKET_ID:
 X64_APPLICATION_FAULT_INVALID_POINTER_READ_uxtheme!_delayLoadHelper2+96

WATSON_STAGEONE_URL:
http://watson.microsoft.com/StageOne/perl_exe/0_0_0_0/51a63046/ntdll_dll/6_1_7601_17725/4ec4aa8e/c0000008/000cd7d8.htm?Retriage=1

Followup: MachineOwner
---------










On Wed, May 22, 2013 at 11:04 PM, bulk88 via RT
<perlbug-followup@perl.org>wrote:

> On Wed May 22 13:57:37 2013, kartlee05 wrote:
> > Hi Folks,
> >
> > We use perl widely for one of our job monitoring application. And
> > recently
> > we received reports from customer that the application crash after few
> > hours with 'invalid handle' exception in ntdll.dll.
> > So we planned to run our application in Application Verifier of
> > Windows to
> > trace handles and having a hard time to run perl under it. Currently
> > the
> > following piece of code extracted in the form of a sample script crash
> > under AppVerifier -
> ....................................................
> > Exactly after notepad.exe process is spawned we see the crash with
> > following stack trace. We see a similar trace at customer site when a
> > handle is being closed through closesocket(..) call which is not
> > really a
> > socket handle. The stack trace given below is from perl-5.10.1. We
> > also see
> > a similar stack trace with 5.14.2. So I am sure this is a problem even
> > in
> > current running version of perl. Can you please take a look and
> > respond
> > back?
>
> NT Kernel does not throw exceptions AKA crashes AKA SEH for
> STATUS_INVALID_HANDLE unless you turn on exotic debugging (GlobalFlag
> key in registry for that image path) for the process, see
>
> http://msdn.microsoft.com/en-us/library/windows/hardware/ff542881%28v=vs.85%29.aspx
> . That is what VS Debugger's invalid handle exceptions are. They are
> made only for debugging purposes and dont happen at normal runtime.
> STATUS_INVALID_HANDLE will be the returned error number for Native API
> call in kernel32. Your customer would never have a crash with
> STATUS_INVALID_HANDLE unless GlobalFlag is set in the registry by
> accident, or some non-MS and non-Perl code did a RaiseException.
>
> What my first guess is that this is a double free-ing of a socket
> handle. My second guess says this is by design, because in
> http://perl5.git.perl.org/perl.git/blob/HEAD:/win32/win32sck.c#l418 all
> unix FDs get closed as a winsock handle, then if winsock doesn't
> recognize it, then close it as a clib FD. The design I think is an
> artifact that under Dos Windows (especially 95, late in 98 SE and ME,
> winsock handles became kernel pipes I think), winsock handles were not
> kernel handles (WSAGetLastError vs GetLastError, on NT WSA version
> forwards to kernel32). On NT, all winsock handles are kernel pipe
> handles belonging to the AFD driver. Note, Win32's/Perl's pipes are
> implemented by a different driver called NPFS. So that is why this hack
> is used to separate sockets from pipes,
>
> http://jakash3.wordpress.com/2012/12/19/getting-file-descriptor-type-in-windows/
> . Calling the generic CloseHandle on a socket is forbidden by MS's docs,
> so that is probably out of the question. I think the current code is
> fine. Someone can argue speed of finding out the handle type and closing
> it once vs blindly closing it with different libraries.
>
>
> 5.14 I think is now out of support since 5.18 was released a few days
> ago. I didn't run any code to write this post.
>
> --
> bulk88 ~ bulk88 at hotmail.com
>

• Re: [perl #118127] Perl crash when run under AppVerifier by Karthik Rajagopalan