5/28/2023 0 Comments Activeperl 5.12.3![]() ![]() Libpth="c:\Program Files\Microsoft Visual Studio. ![]() Ld='link', ldflags ='-nologo -nodefaultlib -debug -libpath:"c:\perl512\lib\CORE" -machine:x86' Ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='_int64', lseeksize=8 Intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234ĭ_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8 Use64bitint=undef, use64bitall=undef, uselongdouble=undefĬc='cl', ccflags ='-nologo -GF -W3 -Od -MD -Zi -DDEBUGGING -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO',Ĭcversion='', gccversion='', gccosandvers='' Useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef Useithreads=define, usemultiplicity=define Hint=recommended, useposix=true, d_sigaction=undef Osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread Summary of my perl5 (revision 5 version 12 subversion 2) configuration: Site configuration information for perl 5.12.2:Ĭonfigured by Owner at Wed Mar 23 08:05:23 2011. I request that the above-reported bug be fixed. Perl_scalarvoid, whatever it does to opcodes, should run in a loop down the optree, not recursively on every opcode and thus eating away the C stack. C Stack remained at many MBs (7 to 8MB at 50000 in test script). On sucessful runs, malloced memory went down from ~60MB inside the module BEGIN block (at "print "after branches\n" ") to ~3MB at runtime ("print "in main\n" " ) according to VMMAP (private/yellow memory). If I lower the 100000 to 50000 in the test script, the script will run without a stack overflow. I wrote this test script to test how efficient Perl is at returning memory to the OS after a Perl Module is "use"d and if, and how well, memory behind the BEGIN blocks (SVs, CVs, Opcodes, pads, raw malloced blocks) is returned to the OS. I assume that the reason that my self-compiled Perl will stack overflow at 16MB and ActivePerls do not is because of high C stack overhead of each recursive Perl_scalarvoid when Perl is compiled with -Od (no registers) meanwhile ActivePerls are compiled with -O1 (small code). On other perl scripts and apps I run, all the interpreter (APs and my compiled Perl) peak at 20-50KB of C stack which is fine. I have not tested doing the "require" at runtime. I know it can be done with VirtualFree and VirtualAlloc on Windows, but that is the wrong way to fix C stack recursion) and wasted, never to be used again after BEGIN blocks run. There is no reason for the interpreter to peak at many MBs of C stack, which is irreversibly expanded (there are OS specific ways to shrink C stacks. If I lower the stack reserve from 16 MB to 256KB in the PE header on perl.exe from ActivePerls, I will get the same exact Perl_scalarvoid stack overflow. While the test script is running, ActivePerls peak at 8 MB on the C stack. I could not replicate this with any stock ActivePerl (AP 5.10.0, AP 5.12.3). If there are too many opcodes, C stack overflows. Perl_scalarvoid calls itself over and over, for what I blindly guess is every opcode in the sub. From Created by lexer (?) has a deep recursion bug in Perl_scalarvoid when given a very large Perl subroutine to run. ![]()
0 Comments
Leave a Reply. |