Sorry to hear about your accident. Glad you're OK.
Your analysis seems to point to Perl being unable to free memory blocks
in Windows (will it happen in Linux as well?). Appending to my
experience, this problem happens when there is a huge block of memory to
release.
I'm not much of a C/C++ developer, so my question is: for those of us
who depend on the ActivePerl track for modperl, is there a workaround we
can use?
You should give your developer a pat on the back for coming up with such
an ingenious workaround!
Issac Goldstand wrote:
It took me a while to get everything together, and I was involved in a
minor pile-up car accident (I'm fine - car needs body work) so this got
delayed more than I originally intended. Apologies to people who were
standing by with test environments to try to work this out.
Getting to the point (quoting this from the developer who was in charge
of this issue):
--- BEGIN QUOTE ---
The crash occurs on computer with Microsoft Windows Server 2003 Standard
Edition Service Pack 1. With dual Intel XEON HyperThreading CPU 3.00 GHZ
and 3.00 GB RAM
We originally found the bug when We used Apache 2.0.2 ,Mod_perl
1.99-dev,Perl 5.8.3, and also the bug still occurred when we upgraded
the server to Apache 2.2.3,Mod_perl 2.0.3 RC2,Perl 5.8.8
The event log message is "Faulting application httpd.exe version
2.2.3.0, faulting module perl58.dll version 0.0.0.0, fault address
0x0015bdb4"
The configuration of the server:
PerlInterpMax 10 and more
# Creates 7 interpreter threads when Apache starts up (def 3)
PerlInterpStart 7 and up
# Leave a maximum of 7 spare threads (not used threads)
PerlInterpMaxSpare 7 and up.
Httpd.conf :
ThreadsPerChild 250
MaxRequestsPerChild 0
After compiling the perl with debug symbols and running it using the
Windbg application I got the following stack trace:
perl58!VMem::Free+0x5e
perl58!CPerlHost::FreeShared+0x2a
perl58!PerlMemSharedFree+0x1a
perl58!Perl_newCONSTUB+0x28a
perl58!S_cv_clone2+0x8ce
perl58!Perl_cv_clone+0x1a
perl58!Perl_pp_anoncode+0x46
perl58!Perl_runops_debug+0x18f
perl58!S_call_body+0x52
perl58!Perl_call_sv+0x703
perl58!S_call_list_body+0x57
perl58!Perl_call_list+0x18a
perl58!Perl_newATTRSUB+0x1306
perl58!Perl_utilize+0x4e3
perl58!Perl_yyparse+0x1543
perl58!S_doeval+0x3a8
perl58!Perl_pp_require+0x19c9
mod_perl!modperl_pp_require+0xd
perl58!Perl_runops_debug+0x18f
perl58!S_call_body+0x52
In order to avoid the problem I used the __try and __catch which are
used in Microsoft win32 applications changing :
inline void FreeShared(void* ptr)
{
GetLockShared();
__try{
m_pVMemShared->Free(ptr);
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
}
FreeLockShared();
};
Located in win32\perlhost.h file.
The crash occurs in VMem::free function probably during freeing of the
block of memory there.
--- END QUOTE ---
Issac
Issac Goldstand wrote:
Unfortunately, so far not yet... We haven't been able to get it to
reproduce on a test machine yet - the setup on the problematic machine
is Dual hyperthreading 3.0Ghz Xeons with 3GB RAM, running Win2003 Server
SP1.
The closest we've got to match that setup is with a dual core Pentium-D
3.4 Ghz machine with XP SP2, or a VMWare VM with 2 virtual processors
(host machine is a Pentium 4-HT 2.8 Ghz machine) with 1.2GB RAM running
win2003 SP1.
I'll post the exact error messages, as well as a workaround that someone
put together (definitely workaround and not fix - he just wraps the
deepest crashing subroutine in a Visual C __try {} block, as I
understand; I haven't seen it myself yet), as soon as I can.
Issac
Randy Kobes wrote:
On Sun, 19 Nov 2006, Issac Goldstand wrote:
Foo JH wrote:
Issac Goldstand wrote:
We were originally using 5.8.3, but reproduced the problem with both
activeperl 5.8.8.819 with mod_perl-2.0.3-dev (from your PPM
repository)
as well as our own built perl + mod_perl 2.0.3-rc2
I wonder if modperl on apache 2.2 will resolve this issue...
We're using 2.2.3 - Upgrading everything to the latest stable versions
was the first thing we tried.
Is it possible to provide a minimal script that illustrates
the problem? There's some people on the list that have
threads-enabled unix setups; it would be interesting to
see if it's also a problem there.
