perlbug-followup at perl
Aug 2, 2012, 4:17 PM
Post #1 of 11
(154 views)
Permalink
|
|
[perl #88840] t/op/fork.t blocks in external process test on Win32
|
|
I am using
__________________________________________________________
C:\>perl -V
Summary of my perl5 (revision 5 version 17 subversion 3 patch blead
2012-08-02.1
5:28:40 4276fd3639b8e3fdebe28a2eb81d455f0f33fd05 v5.17.2-193-g4276fd3)
configura
tion:
Snapshot of: 4276fd3639b8e3fdebe28a2eb81d455f0f33fd05
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 -Od -MD -Zi -DDEBUGGING
-fp:precise -DWIN
32 -D_CONSOLE -DNO_STRICT -DWIN64 -DCONSERVATIVE
-D_CRT_SECURE_NO_DEPRECATE -D_C
RT_NONSTDC_NO_DEPRECATE -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT
-DPERL_
IMPLICIT_SYS -DUSE_PERLIO',
optimize='-Od -MD -Zi -DDEBUGGING -fp:precise',
cppflags='-DWIN32'
ccversion='15.00.30729.01', 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', lsee
ksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='link', ldflags ='-nologo -nodefaultlib -debug
-libpath:"c:\p517\lib\COR
E" -machine:AMD64 "/manifestdependency:type='Win32'
name='Microsoft.Windows.Com
mon-Controls' version='6.0.0.0' processorArchitecture='*'
publicKeyToken='6595b6
4144ccf1df' language='*'"'
libpth=\lib
libs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.l
ib 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
perllibs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg
32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib
uuid.lib ws
2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib
comctl32.lib msv
crt.lib
libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl517.lib
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug
-libpath:"c:\p
517\lib\CORE" -machine:AMD64 "/manifestdependency:type='Win32'
name='Microsoft.
Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*'
publicKeyTo
ken='6595b64144ccf1df' language='*'"'
Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING HAS_TIMES HAVE_INTERP_INTERN MULTIPLICITY
PERLIO_LAYERS PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS
PERL_MALLOC_WRAP 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_PERLIO
USE_PERL_ATOF
Built under MSWin32
Compiled at Aug 2 2012 17:01:32
@INC:
C:/p517/site/lib
C:/p517/lib
.
C:\>
______________________________________________________________
VS 2008 and Server 2003 x64, and a x64 perl.
The /op/fork.t freeze is this being run "perl -e "if ($pid=fork){kill(9,
$pid)} else {sleep 5}"".
The callstack from the only thread at that point in the process is
___________________________________________________
ntdll.dll!ZwWaitForSingleObject() + 0xa bytes
ntdll.dll!RtlpWaitOnCriticalSection() - 0x1aa bytes
ntdll.dll!LdrUnloadDll() - 0x1d9a0 bytes
kernel32.dll!FreeLibrary() + 0x71 bytes
> perl517.dll!VMem::~VMem() Line 159 C++
perl517.dll!VMem::`scalar deleting destructor'() + 0x17 bytes C++
perl517.dll!VMem::Release() Line 268 + 0x2b bytes C++
perl517.dll!CPerlHost::~CPerlHost() Line 2081 C++
perl517.dll!CPerlHost::`scalar deleting destructor'() + 0x17 bytes C++
perl517.dll!win32_delete_internal_host(void * h=0x0000000000346e60)
Line 202 + 0x2b bytes C++
perl517.dll!perl_free(interpreter * my_perl=0x0000000001aa6a08)
Line 1335 C
perl517.dll!RunPerl(int argc=3, char * * argv=0x0000000000343d90, char
* * env=0x00000000003441b0) Line 277 C++
perl.exe!main(int argc=3, char * * argv=0x0000000000343d90, char * *
env=0x0000000000344820) Line 24 C
perl.exe!__tmainCRTStartup() Line 586 + 0x19 bytes C
kernel32.dll!BaseProcessStart() + 0x2c bytes
__________________________________________________
This is the parent "process" in ithreads, the child thread would have a
different callstack begining.
In vmem.h at line 158.
_____________________________________________
VMem::~VMem(void)
{
#ifdef _USE_LINKED_LIST
while (m_Dummy.pNext != &m_Dummy) {
Free(m_Dummy.pNext+1);
}
#endif
if (m_hLib)
FreeLibrary(m_hLib);
DeleteCriticalSection(&m_cs);
}
____________________________________________
m_hLib is 0x000007ff7fc00000 which is C:\WINDOWS\system32\msvcrt.dll
according to Process Explorer (HMODULEs are pointers to a memory mapped
DLL PE file header). The problem with vmem.h is that it calls msvcrt.dll
instead of being hard coded to whatever the static linked malloc or
static linked CRT is, so 2 CRTs wind up in the process space always
unless its compiled with Platform SDK or VC 6 (ActivePerl is made this
way) which doesnt use VS specific CRTs but msvcrt.dll for a c std lib.
This is an optimization issue but is not the cause of the deadlock,
since vmem.h and msvcrt.dll have been around for almost a decade ( added
in
http://perl5.git.perl.org/perl.git/commit/f57e8d3bb1a36000e1951a4d2d5b0104b39bde4b
)
So I got private symbol global variable "LdrpLoaderLock" (google it)
from ntdll and dumped it.
---
via perlbug: queue: perl5 status: new
https://rt.perl.org:443/rt3/Ticket/Display.html?id=88840
|
ldrpdump.PNG
0001-fix-RT-88840-don-t-terminate-a-child-fork-psuedo-pro.patch
