You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Markus Wichitill <ma...@gmx.de> on 2004/08/15 16:40:40 UTC
[mp2] t\filter\in_bbs_inject_header.t crashes when run alone
While running t\SMOKE last night for the ithreads scalar leak issue didn't
help with the leak issue itself, it made t\filter\in_bbs_inject_header.t
crash Apache 2.0.50/Win32 when the test is run by itself, which I can
reproduce manually. As part of the whole sequence, the test succeeds.
So I finally decided to set up my own debug builds of Perl and Apache in
addition to my normally used AS and ASF binaries. Compiling and installing
Perl and Apache worked fine, however when I run "nmake test" of mod_perl
CVS, the Apache startup fails early with the following odd error messages.
The code pointed to by the messages looks perfectly fine to me.
[...]
C:\Dev\test\perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST -clean
C:\Dev\test\perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST
-bugreport -verbose=0
"my" variable $script masks earlier declaration in same scope at
C:\Dev\src\modperl-2.0\t\response\TestApache\subprocess.pm line 64.
Compilation failed in require at
C:/Dev/test/perl/site/lib/Apache/TestConfigPerl.pm line 593.
Can't use global @_ in "my" at
C:\Dev\src\modperl-2.0\blib\lib/Apache/XSLoader.pm line 30, near "(@_"
Compilation failed in require at
C:\Dev\src\modperl-2.0\blib\lib/Apache/RequestRec.pm line 24.
BEGIN failed--compilation aborted at
C:\Dev\src\modperl-2.0\blib\lib/Apache/RequestRec.pm line 24.
Compilation failed in require at
C:\Dev\src\modperl-2.0\t\response\TestDirective\perlmodule.pm line 12.
BEGIN failed--compilation aborted at
C:\Dev\src\modperl-2.0\t\response\TestDirective\perlmodule.pm line 12.
Compilation failed in require at
C:/Dev/test/perl/site/lib/Apache/TestConfigPerl.pm line 593.
Undefined subroutine &Apache::XSLoader::load called at
C:\Dev\src\modperl-2.0\blib\lib/Apache/RequestIO.pm line 26.
Compilation failed in require at
C:\Dev\src\modperl-2.0\t\response\TestDirective\perlrequire.pm line 15.
BEGIN failed--compilation aborted at
C:\Dev\src\modperl-2.0\t\response\TestDirective\perlrequire.pm line 15.
Compilation failed in require at
C:/Dev/test/perl/site/lib/Apache/TestConfigPerl.pm line 593.
[...]
The builds use the defaults options, only with debugging enabled and the
install path set.
BTW, the segfault resolving instructions in /docs/2.0/user/help/help.html
are Unix-only, if building Apache with Apache.dsw/"Win32 Debug" and Perl
with "CFG=Debug" in the Makefile isn't enough, let me know.
*** mod_perl version 1.9915
*** using C:\Dev\src\modperl-2.0\lib\Apache\BuildConfig.pm
*** Makefile.PL options:
MP_APR_LIB => aprext
MP_AP_PREFIX => C:\dev\test\apache2
MP_COMPAT_1X => 1
MP_DEBUG => 1
MP_GENERATE_XS => 1
MP_LIBNAME => mod_perl
MP_TRACE => 1
MP_USE_DSO => 1
MP_USE_STATIC => 1
*** C:\dev\test\apache2\bin\Apache.EXE -V
Server version: Apache/2.0.50
Server built: Aug 15 2004 14:06:59
Server's Module Magic Number: 20020903:8
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/winnt"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/apache"
-D SUEXEC_BIN="/apache/bin/suexec"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error.log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
*** (apr|apu)-config linking info
/libpath:"C:\dev\test\apache2\lib" libapr.lib
/libpath:"C:\dev\test\apache2\lib" libaprutil.lib
*** c:\dev\test\perl\bin\perl.exe -V
Summary of my perl5 (revision 5 version 8 subversion 5) configuration:
Platform:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
usethreads=undef use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='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 -DPERL_MSVCRT_READFIX',
optimize='-Od -MD -Zi -DDEBUGGING',
cppflags='-DWIN32'
ccversion='', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='link', ldflags ='-nologo -nodefaultlib -debug
-libpath:"c:\dev\test\perl\lib\CORE" -machine:x86'
libpth=\lib
libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib
uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.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 wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib
msvcrt.lib
libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
gnulibc_version='undef'
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug
-libpath:"c:\dev\test\perl\lib\CORE" -machine:x86'
Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS
Built under MSWin32
Compiled at Aug 15 2004 13:26:47
%ENV:
PERL_LWP_USE_HTTP_10="1"
@INC:
c:/Dev/test/perl/lib
c:/Dev/test/perl/site/lib
.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 15 Aug 2004, Stas Bekman wrote:
> Markus Wichitill wrote:
[ .. ]
> > [Sun Aug 15 21:56:45 2004] [error] Can't locate
> > ApacheTest/PerlRequireTest.pm in @INC (@INC contains: C:\\Dev\\src\\modp
> > erl-2.0-test\\t\\response C:\\Dev\\src\\modperl-2.0-test\\t\\protocol
> > C:\\Dev\\src\\modperl-2.0-test\\t\\preconnection C
> > :\\Dev\\src\\modperl-2.0-test\\t\\hooks
> > C:\\Dev\\src\\modperl-2.0-test\\t\\filter
> > C:\\Dev\\src\\modperl-2.0-test\\blib\\
> > lib C:\\Dev\\src\\modperl-2.0-test\\blib\\arch
> > C:/Dev/src/modperl-2.0-test/t C:/Dev/src/modperl-2.0-test/t/htdocs/testdi
> > rective/perlmodule-vh
> > C:/Dev/src/modperl-2.0-test/t/htdocs/testdirective/main
> > C:/Dev/test/perl/lib C:/Dev/test/perl/site
> > /lib C:/Dev/src/modperl-2.0-test/t/
> > C:/Dev/src/modperl-2.0-test/t/lib/perl) at (eval 24) line 1.\n
> > [Sun Aug 15 21:56:45 2004] [error] Can't load Perl file:
> > ApacheTest/PerlRequireTest.pm for server localhost:8529, exitin
> > g...
> > Note the errors or messages above, and press the <ESC> key to exit. 11....
>
> why does it try to load ApacheTest/PerlRequireTest.pm? Why ApacheTest as a
> single word?
Although this problem seems to have sorted itself out, for
the archives, it's strange that the directories are reported
with escaped backslashes (\\) - I've not seen that before in
this context. Also, the presence of "ApacheTest" as one word
might have resulted from something like "Apache\Test" being
used, which again is wierd ...
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Stas Bekman <st...@stason.org>.
Markus Wichitill wrote:
> Stas Bekman wrote:
>
>> Markus Wichitill wrote:
>>
>>> While running t\SMOKE last night for the ithreads scalar leak issue
>>> didn't help with the leak issue itself, it made
>>> t\filter\in_bbs_inject_header.t crash Apache 2.0.50/Win32 when the
>>> test is run by itself, which I can reproduce manually. As part of the
>>> whole sequence, the test succeeds.
>>
>>
>> Can you revert it to version 1.9?
>> and try again?
>
>
> Still crashes. Not always though, it's random (with both revs).
>
>>> So I finally decided to set up my own debug builds of Perl and Apache
>>> in addition to my normally used AS and ASF binaries. Compiling and
>>> installing Perl and Apache worked fine, however when I run "nmake
>>> test" of mod_perl CVS, the Apache startup fails early with the
>>> following odd error messages. The code pointed to by the messages
>>> looks perfectly fine to me.
>>>
>>> [...]
>>
>> That doesn't make sense, it's properly scoped. it must be perl getting
>> confused because of some other unrelated error. What test do you get
>> his error from?
>>
>> and all these? where do they come from?
>
>
> The whole block is from the startup phase, before any tests are run.
> Full output:
>
> C:\Dev\src\modperl-2.0-test>nmake test
>
> Microsoft (R) Program Maintenance Utility Version 6.00.9782.0
> Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
>
> cd "src/modules/perl" && nmake -f Makefile.modperl
>
> Microsoft (R) Program Maintenance Utility Version 6.00.9782.0
> Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
>
> cd "xs\APR\aprext" && nmake all -nologo
> PERL="c:\dev\test\perl\bin\perl.exe" DEFINE="-DMP_HAVE_APR_LIBS" LINKTYP
> E="static"
> c:\dev\test\perl\bin\perl.exe -MExtUtils::Command -e cp
> bin/mp2doc blib\script\mp2doc
> pl2bat.bat blib\script\mp2doc
> c:\dev\test\perl\bin\perl.exe -MExtUtils::Command -e cp
> bin/mp2bug blib\script\mp2bug
> pl2bat.bat blib\script\mp2bug
> C:\Dev\test\perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST -clean
> C:\Dev\test\perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST
> -bugreport -verbose=0
> "my" variable $script masks earlier declaration in same scope at
> C:\Dev\src\modperl-2.0-test\t\response\TestApache\subpr
> ocess.pm line 64.
> Compilation failed in require at
> C:/Dev/test/perl/site/lib/Apache/TestConfigPerl.pm line 593.
> Can't use global @_ in "my" at
> C:\Dev\src\modperl-2.0-test\blib\lib/Apache/XSLoader.pm line 30, near "(@_"
> Compilation failed in require at
> C:\Dev\src\modperl-2.0-test\blib\lib/Apache/RequestRec.pm line 24.
> BEGIN failed--compilation aborted at
> C:\Dev\src\modperl-2.0-test\blib\lib/Apache/RequestRec.pm line 24.
> Compilation failed in require at
> C:\Dev\src\modperl-2.0-test\t\response\TestDirective\perlmodule.pm line 12.
> BEGIN failed--compilation aborted at
> C:\Dev\src\modperl-2.0-test\t\response\TestDirective\perlmodule.pm line 12.
> Compilation failed in require at
> C:/Dev/test/perl/site/lib/Apache/TestConfigPerl.pm line 593.
> Undefined subroutine &Apache::XSLoader::load called at
> C:\Dev\src\modperl-2.0-test\blib\lib/Apache/RequestIO.pm line 26.
>
> Compilation failed in require at
> C:\Dev\src\modperl-2.0-test\t\response\TestDirective\perlrequire.pm line
> 15.
> BEGIN failed--compilation aborted at
> C:\Dev\src\modperl-2.0-test\t\response\TestDirective\perlrequire.pm line
> 15.
> Compilation failed in require at
> C:/Dev/test/perl/site/lib/Apache/TestConfigPerl.pm line 593.
Is this one error stack or a bunch of unrelated errors? Any help if you setup:
use Carp;
$SIG{__DIE__} = \&Carp::confess;
at the beginning of t/conf/modperl_extra.pl
> C:\dev\test\apache2\bin\Apache.EXE -d C:/Dev/src/modperl-2.0-test/t -f
> C:/Dev/src/modperl-2.0-test/t/conf/httpd.conf -D
> APACHE2 -D PERL_USEITHREADS
> using Apache/2.0.50 (winnt MPM)
>
> waiting 300 seconds for server to start: ...[Sun Aug 15 21:56:45 2004]
> [info] 26 Apache:: modules loaded
> [Sun Aug 15 21:56:45 2004] [info] 7 APR:: modules loaded
> [Sun Aug 15 21:56:45 2004] [info] base server + 21 vhosts ready to run
> tests
> [Sun Aug 15 21:56:45 2004] [error] Can't locate
> ApacheTest/PerlRequireTest.pm in @INC (@INC contains: C:\\Dev\\src\\modp
> erl-2.0-test\\t\\response C:\\Dev\\src\\modperl-2.0-test\\t\\protocol
> C:\\Dev\\src\\modperl-2.0-test\\t\\preconnection C
> :\\Dev\\src\\modperl-2.0-test\\t\\hooks
> C:\\Dev\\src\\modperl-2.0-test\\t\\filter
> C:\\Dev\\src\\modperl-2.0-test\\blib\\
> lib C:\\Dev\\src\\modperl-2.0-test\\blib\\arch
> C:/Dev/src/modperl-2.0-test/t C:/Dev/src/modperl-2.0-test/t/htdocs/testdi
> rective/perlmodule-vh
> C:/Dev/src/modperl-2.0-test/t/htdocs/testdirective/main
> C:/Dev/test/perl/lib C:/Dev/test/perl/site
> /lib C:/Dev/src/modperl-2.0-test/t/
> C:/Dev/src/modperl-2.0-test/t/lib/perl) at (eval 24) line 1.\n
> [Sun Aug 15 21:56:45 2004] [error] Can't load Perl file:
> ApacheTest/PerlRequireTest.pm for server localhost:8529, exitin
> g...
> Note the errors or messages above, and press the <ESC> key to exit. 11....
why does it try to load ApacheTest/PerlRequireTest.pm? Why ApacheTest as a
single word?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Markus Wichitill <ma...@gmx.de>.
Stas Bekman wrote:
> Markus Wichitill wrote:
>> While running t\SMOKE last night for the ithreads scalar leak issue
>> didn't help with the leak issue itself, it made
>> t\filter\in_bbs_inject_header.t crash Apache 2.0.50/Win32 when the
>> test is run by itself, which I can reproduce manually. As part of the
>> whole sequence, the test succeeds.
>
> Can you revert it to version 1.9?
> and try again?
Still crashes. Not always though, it's random (with both revs).
>> So I finally decided to set up my own debug builds of Perl and Apache
>> in addition to my normally used AS and ASF binaries. Compiling and
>> installing Perl and Apache worked fine, however when I run "nmake
>> test" of mod_perl CVS, the Apache startup fails early with the
>> following odd error messages. The code pointed to by the messages
>> looks perfectly fine to me.
>>
>> [...]
> That doesn't make sense, it's properly scoped. it must be perl getting
> confused because of some other unrelated error. What test do you get his
> error from?
>
> and all these? where do they come from?
The whole block is from the startup phase, before any tests are run. Full
output:
C:\Dev\src\modperl-2.0-test>nmake test
Microsoft (R) Program Maintenance Utility Version 6.00.9782.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
cd "src/modules/perl" && nmake -f Makefile.modperl
Microsoft (R) Program Maintenance Utility Version 6.00.9782.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
cd "xs\APR\aprext" && nmake all -nologo
PERL="c:\dev\test\perl\bin\perl.exe" DEFINE="-DMP_HAVE_APR_LIBS" LINKTYP
E="static"
c:\dev\test\perl\bin\perl.exe -MExtUtils::Command -e cp bin/mp2doc
blib\script\mp2doc
pl2bat.bat blib\script\mp2doc
c:\dev\test\perl\bin\perl.exe -MExtUtils::Command -e cp bin/mp2bug
blib\script\mp2bug
pl2bat.bat blib\script\mp2bug
C:\Dev\test\perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST -clean
C:\Dev\test\perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST
-bugreport -verbose=0
"my" variable $script masks earlier declaration in same scope at
C:\Dev\src\modperl-2.0-test\t\response\TestApache\subpr
ocess.pm line 64.
Compilation failed in require at
C:/Dev/test/perl/site/lib/Apache/TestConfigPerl.pm line 593.
Can't use global @_ in "my" at
C:\Dev\src\modperl-2.0-test\blib\lib/Apache/XSLoader.pm line 30, near "(@_"
Compilation failed in require at
C:\Dev\src\modperl-2.0-test\blib\lib/Apache/RequestRec.pm line 24.
BEGIN failed--compilation aborted at
C:\Dev\src\modperl-2.0-test\blib\lib/Apache/RequestRec.pm line 24.
Compilation failed in require at
C:\Dev\src\modperl-2.0-test\t\response\TestDirective\perlmodule.pm line 12.
BEGIN failed--compilation aborted at
C:\Dev\src\modperl-2.0-test\t\response\TestDirective\perlmodule.pm line 12.
Compilation failed in require at
C:/Dev/test/perl/site/lib/Apache/TestConfigPerl.pm line 593.
Undefined subroutine &Apache::XSLoader::load called at
C:\Dev\src\modperl-2.0-test\blib\lib/Apache/RequestIO.pm line 26.
Compilation failed in require at
C:\Dev\src\modperl-2.0-test\t\response\TestDirective\perlrequire.pm line 15.
BEGIN failed--compilation aborted at
C:\Dev\src\modperl-2.0-test\t\response\TestDirective\perlrequire.pm line 15.
Compilation failed in require at
C:/Dev/test/perl/site/lib/Apache/TestConfigPerl.pm line 593.
C:\dev\test\apache2\bin\Apache.EXE -d C:/Dev/src/modperl-2.0-test/t -f
C:/Dev/src/modperl-2.0-test/t/conf/httpd.conf -D
APACHE2 -D PERL_USEITHREADS
using Apache/2.0.50 (winnt MPM)
waiting 300 seconds for server to start: ...[Sun Aug 15 21:56:45 2004]
[info] 26 Apache:: modules loaded
[Sun Aug 15 21:56:45 2004] [info] 7 APR:: modules loaded
[Sun Aug 15 21:56:45 2004] [info] base server + 21 vhosts ready to run tests
[Sun Aug 15 21:56:45 2004] [error] Can't locate
ApacheTest/PerlRequireTest.pm in @INC (@INC contains: C:\\Dev\\src\\modp
erl-2.0-test\\t\\response C:\\Dev\\src\\modperl-2.0-test\\t\\protocol
C:\\Dev\\src\\modperl-2.0-test\\t\\preconnection C
:\\Dev\\src\\modperl-2.0-test\\t\\hooks
C:\\Dev\\src\\modperl-2.0-test\\t\\filter C:\\Dev\\src\\modperl-2.0-test\\blib\\
lib C:\\Dev\\src\\modperl-2.0-test\\blib\\arch C:/Dev/src/modperl-2.0-test/t
C:/Dev/src/modperl-2.0-test/t/htdocs/testdi
rective/perlmodule-vh
C:/Dev/src/modperl-2.0-test/t/htdocs/testdirective/main C:/Dev/test/perl/lib
C:/Dev/test/perl/site
/lib C:/Dev/src/modperl-2.0-test/t/ C:/Dev/src/modperl-2.0-test/t/lib/perl)
at (eval 24) line 1.\n
[Sun Aug 15 21:56:45 2004] [error] Can't load Perl file:
ApacheTest/PerlRequireTest.pm for server localhost:8529, exitin
g...
Note the errors or messages above, and press the <ESC> key to exit. 11....
ESC doesn't exit BTW, have to kill the console.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Stas Bekman <st...@stason.org>.
Markus Wichitill wrote:
> While running t\SMOKE last night for the ithreads scalar leak issue
> didn't help with the leak issue itself, it made
> t\filter\in_bbs_inject_header.t crash Apache 2.0.50/Win32 when the test
> is run by itself, which I can reproduce manually. As part of the whole
> sequence, the test succeeds.
Can you revert it to version 1.9?
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/t/filter/TestFilter/in_bbs_inject_header.pm
and try again?
> So I finally decided to set up my own debug builds of Perl and Apache in
> addition to my normally used AS and ASF binaries. Compiling and
> installing Perl and Apache worked fine, however when I run "nmake test"
> of mod_perl CVS, the Apache startup fails early with the following odd
> error messages. The code pointed to by the messages looks perfectly fine
> to me.
>
> [...]
> C:\Dev\test\perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST -clean
> C:\Dev\test\perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST
> -bugreport -verbose=0
> "my" variable $script masks earlier declaration in same scope at
> C:\Dev\src\modperl-2.0\t\response\TestApache\subprocess.pm line 64.
That doesn't make sense, it's properly scoped. it must be perl getting
confused because of some other unrelated error. What test do you get his
error from?
> Compilation failed in require at
> C:/Dev/test/perl/site/lib/Apache/TestConfigPerl.pm line 593.
> Can't use global @_ in "my" at
> C:\Dev\src\modperl-2.0\blib\lib/Apache/XSLoader.pm line 30, near "(@_"
> Compilation failed in require at
> C:\Dev\src\modperl-2.0\blib\lib/Apache/RequestRec.pm line 24.
> BEGIN failed--compilation aborted at
> C:\Dev\src\modperl-2.0\blib\lib/Apache/RequestRec.pm line 24.
> Compilation failed in require at
> C:\Dev\src\modperl-2.0\t\response\TestDirective\perlmodule.pm line 12.
> BEGIN failed--compilation aborted at
> C:\Dev\src\modperl-2.0\t\response\TestDirective\perlmodule.pm line 12.
> Compilation failed in require at
> C:/Dev/test/perl/site/lib/Apache/TestConfigPerl.pm line 593.
> Undefined subroutine &Apache::XSLoader::load called at
> C:\Dev\src\modperl-2.0\blib\lib/Apache/RequestIO.pm line 26.
> Compilation failed in require at
> C:\Dev\src\modperl-2.0\t\response\TestDirective\perlrequire.pm line 15.
> BEGIN failed--compilation aborted at
> C:\Dev\src\modperl-2.0\t\response\TestDirective\perlrequire.pm line 15.
> Compilation failed in require at
> C:/Dev/test/perl/site/lib/Apache/TestConfigPerl.pm line 593.
> [...]
and all these? where do they come from?
> The builds use the defaults options, only with debugging enabled and the
> install path set.
>
> BTW, the segfault resolving instructions in
> /docs/2.0/user/help/help.html are Unix-only, if building Apache with
> Apache.dsw/"Win32 Debug" and Perl with "CFG=Debug" in the Makefile isn't
> enough, let me know.
well, a patch that includes information specific to win32 is very welcome.
Thanks.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Markus Wichitill <ma...@gmx.de>.
Stas Bekman wrote:
>>> Incidently, this module does the same as this test and more:
>>> http://apache.org/~stas/Apache-Filter-HTTPHeadersFixup-0.04.tar.gz
>>> Could you give it a try? Make sure that you first build and install
>>> the latest mod_perl cvs (i just checked it some A-T fix). Thanks.
>>
>> Crashes on t\manip\out_append.t #1, with no useful error_log either.
>
> And this module? After you do 'make install' of mod_perl of course! ;)
Works, too.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Stas Bekman <st...@stason.org>.
Markus Wichitill wrote:
>> Incidently, this module does the same as this test and more:
>> http://apache.org/~stas/Apache-Filter-HTTPHeadersFixup-0.04.tar.gz
>> Could you give it a try? Make sure that you first build and install
>> the latest mod_perl cvs (i just checked it some A-T fix). Thanks.
>
>
> Crashes on t\manip\out_append.t #1, with no useful error_log either.
And this module? After you do 'make install' of mod_perl of course! ;)
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Markus Wichitill <ma...@gmx.de>.
Randy Kobes wrote:
> I'll take a look at this when I get back too, just to
> compare ... I think you mentioned this earlier, but
> just to confirm - everything (Perl, Apache, mod_perl) was
> compiled with VS7? I've heard of problems trying to
> mix stuff compiled with VS7 and VC++ 6 (which is
> what the Apache and ActivePerl binaries are compiled with).
No, I only use VC6. The VS7/MDM debugger stuff that had apparently sabotaged
the VC6 debugger must've come with other MS products, probably Office,
and/or the .NET runtime, which had also left its traces in the popup mess. I
haven't done any VC/Win32 development for a few years, so haven't fixed this
earlier. I think I did mention the free VCToolkit stuff a while ago, but I
haven't used that so far.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 17 Aug 2004, Markus Wichitill wrote:
> Randy Kobes wrote:
> >>>Crashes on t\manip\out_append.t #1, with no useful error_log either.
> > Is this a crash, in the sense that a pop-up window
> > appears with a message about, eg, an access violation?
>
> It's a "The command in 0x12345678 points to memory in 0x12345678. The action
> 'read' couldn't be performed on the memory"-type popup.
>
> When I press cancel to debug, there are some more popups from the .NET CLR
> and the MDM or whatever that say that VS7 debugger won't run, and ask if I
> want to use the previously installed debugger (VC6) instead.
I'll take a look at this when I get back too, just to
compare ... I think you mentioned this earlier, but
just to confirm - everything (Perl, Apache, mod_perl) was
compiled with VS7? I've heard of problems trying to
mix stuff compiled with VS7 and VC++ 6 (which is
what the Apache and ActivePerl binaries are compiled with).
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Markus Wichitill <ma...@gmx.de>.
Randy Kobes wrote:
>>>Crashes on t\manip\out_append.t #1, with no useful error_log either.
> Is this a crash, in the sense that a pop-up window
> appears with a message about, eg, an access violation?
It's a "The command in 0x12345678 points to memory in 0x12345678. The action
'read' couldn't be performed on the memory"-type popup.
When I press cancel to debug, there are some more popups from the .NET CLR
and the MDM or whatever that say that VS7 debugger won't run, and ask if I
want to use the previously installed debugger (VC6) instead.
Since those extra dialogs were rather annoying, I finally got rid of them by
editing keys in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug,
and guess what, now I actually get useful debugger output:
Perl_safesysmalloc(unsigned int 72) line 67 + 28 bytes
modperl_filter_new(ap_filter_t * 0x00a10560, apr_bucket_brigade *
0x00a39a80, int 0, int 1, int 0, __int64 0) line 316 + 7 bytes
modperl_input_filter_handler(ap_filter_t * 0x00a10560, apr_bucket_brigade *
0x00a39a80, int 1, int 0, __int64 0) line 905 + 31 bytes
ap_get_brigade(ap_filter_t * 0x00a10560, apr_bucket_brigade * 0x00a39a80,
int 1, int 0, __int64 0) line 475 + 32 bytes
net_time_filter(ap_filter_t * 0x00a39a20, apr_bucket_brigade * 0x00a39a80,
int 1, int 0, __int64 0) line 3601
ap_get_brigade(ap_filter_t * 0x00a39a20, apr_bucket_brigade * 0x00a39a80,
int 1, int 0, __int64 0) line 475 + 32 bytes
ap_rgetline_core(char * * 0x00a38c30, unsigned int 8192, unsigned int *
0x04d7fed0, request_rec * 0x00a38c18, int 0, apr_bucket_brigade *
0x00a39a80) line 215 + 27 bytes
read_request_line(request_rec * 0x00a38c18, apr_bucket_brigade * 0x00a39a80)
line 593 + 39 bytes
ap_read_request(conn_rec * 0x00a10200) line 886 + 13 bytes
ap_process_http_connection(conn_rec * 0x00a10200) line 243 + 9 bytes
ap_run_process_connection(conn_rec * 0x00a10200) line 42 + 78 bytes
ap_process_connection(conn_rec * 0x00a10200, void * 0x00a10130) line 177
worker_main(long 1) line 720
_threadstartex(void * 0x0028cc50) line 227 + 13 bytes
KERNEL32! 7c80b50b()
"ptr = (Malloc_t)PerlMem_malloc(size?size:1)" causes the acccess violation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 15 Aug 2004, Stas Bekman wrote:
> Markus Wichitill wrote:
> > Stas Bekman wrote:
> >
> >>> t\filter\in_bbs_inject_header.t always succeeds when run as part of
> >>> the whole "nmake new" run, and only sometimes crashes Apache when run
> >>> alone, which was only uncovered by last night's SMOKE run.
> >> and post the output (client + error_log) of that last run. Thanks.
> >
> >
> > C:\Dev\src\modperl-2.0-test>c:\dev\test\perl\bin\perl t\TEST -v -run
> > t/filter/in_bbs_inject_header.t
> > t\filter\in_bbs_inject_header....# connecting to localhost:8545
> > 1..36
> > # Running under perl version 5.008005 for MSWin32
> > # Current time local: Mon Aug 16 01:51:33 2004
> > # Current time GMT: Sun Aug 15 23:51:33 2004
> > # Using Test.pm version 1.25
> > # Using Apache/Test.pm version 1.13
> > request has failed (the response code was: 500)
> > see t/logs/error_log for more details
> > dubious
> > Test returned status 9 (wstat 2304, 0x900)
> > DIED. FAILED tests 1-36
> > Failed 36/36 tests, 0.00% okay
> > Failed Test Stat Wstat Total Fail Failed List of
> > Failed
> > -------------------------------------------------------------------------------
> >
> > t\filter\in_bbs_inject_header.t 9 2304 36 72 200.00% 1-36
> > Failed 1/1 test scripts, 0.00% okay. 36/36 subtests failed, 0.00% okay.
> > [ error] error running tests (please examine t\logs\error_log)
> >
> > Nothing interesting in the log:
> >
> > [...]
> > [Mon Aug 16 01:51:29 2004] [debug] child.c(684): Child 1160: Worker
> > thread 49 starting.
> > [eof]
>
> Right, a debugger is needed here.
>
> The fact is that it fails on its own but not when running after some other
> tests tells me that something happens that helps the test. It's probably
> not easy as there are many tests but if you do a binary search you may
> find relatively quickly what specific test (or a combination of) makes it
> successful. That what t/SMOKE would have done for you, but here were are
> trying to find the successful sequence, not the failing one.
>
> >> Incidently, this module does the same as this test and more:
> >> http://apache.org/~stas/Apache-Filter-HTTPHeadersFixup-0.04.tar.gz
> >> Could you give it a try? Make sure that you first build and install
> >> the latest mod_perl cvs (i just checked it some A-T fix). Thanks.
> >
> >
> > Crashes on t\manip\out_append.t #1, with no useful error_log either.
>
> Good to hear that. At least the error is consistent.
>
> The fact is that it fails on its own but not when running after some other
> tests tells me that something happens that helps the test.
>
> > Maybe we should just wait until Randy is back home, unless someone can
> > give me VC6 debugging advice.
>
> We can always exclude some tests from the release and resolve them later,
> if that is not resolved by the release time.
Is this a crash, in the sense that a pop-up window
appears with a message about, eg, an access violation?
Or is it "just" a regular server error? If the latter,
what one can do to run the debugger is to put a pause
in the test to give you time to launch VC++ and attach
the debugger to the Apache process before the error
happens.
I'll take a look at this when I get back on the weekend.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Stas Bekman <st...@stason.org>.
Markus Wichitill wrote:
> Stas Bekman wrote:
>
>>> May be we just drop safemalloc, and use the plain old malloc, or now
>>> that we are more educated with apache internals the right solution
>>> seems to be to create a sub-pool and use it to allocate memory. Let
>>> me try to work on that first.
>>
>>
>> OK, Steve and/or Markus, please try with the current cvs, I've now
>> replaced perl's safemalloc with a subpool, that should get rid of the
>> issue.
>
>
> It does, thanks.
Great, thanks Markus!
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Steve Hay <st...@uk.radan.com>.
Markus Wichitill wrote:
>Stas Bekman wrote:
>
>
>>>May be we just drop safemalloc, and use the plain old malloc, or now
>>>that we are more educated with apache internals the right solution
>>>seems to be to create a sub-pool and use it to allocate memory. Let me
>>>try to work on that first.
>>>
>>>
>>OK, Steve and/or Markus, please try with the current cvs, I've now
>>replaced perl's safemalloc with a subpool, that should get rid of the
>>issue.
>>
>>
>
>It does, thanks.
>
Always difficult to be sure with this kind of intermittent failure, but
I've run it a couple of dozen times over now and not seen any failures
either.
Thanks, Stas.
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Markus Wichitill <ma...@gmx.de>.
Stas Bekman wrote:
>> May be we just drop safemalloc, and use the plain old malloc, or now
>> that we are more educated with apache internals the right solution
>> seems to be to create a sub-pool and use it to allocate memory. Let me
>> try to work on that first.
>
> OK, Steve and/or Markus, please try with the current cvs, I've now
> replaced perl's safemalloc with a subpool, that should get rid of the
> issue.
It does, thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Stas Bekman <st...@stason.org>.
> May be we just drop safemalloc, and use the plain old malloc, or now
> that we are more educated with apache internals the right solution seems
> to be to create a sub-pool and use it to allocate memory. Let me try to
> work on that first.
OK, Steve and/or Markus, please try with the current cvs, I've now
replaced perl's safemalloc with a subpool, that should get rid of the issue.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
>
>
>>Steve Hay wrote:
>>
>>
>>
>>
>>>>>>>t\filter\in_bbs_inject_header.t always succeeds when run as part of
>>>>>>>the whole "nmake new" run, and only sometimes crashes Apache when run
>>>>>>>alone, which was only uncovered by last night's SMOKE run.
>>>>>>>
>>>>>>>
>>
>>
>>
>>
>>>After numerous attempts, mine finally failed (running in isolation)
>>>too.
>>>
>>>
>>
>>You mean, it's a random thing, right?
>>
>
> Yes.
>
>
>>
>>
>>
>>>Here's the stacktrace (using perl-5.8.4):
>>>
>>>Perl_safesysmalloc(unsigned int 268467750) line 67 + 11 bytes
>>>modperl_input_filter_handler(ap_filter_t * 0x6eec8410
>>>apr_pool_cleanup_null(void *), apr_bucket_brigade * 0x02b3c950, int
>>>45337120, int 0, __int64 10888566729080832) line 905 + 23 bytes
>>>
>>>
>>
>>so where is that line 905? what mod_perl code has caused that malloc call?
>>
>
> That was using a release build with (some) debugging symbols. Looks
> like some stuff was missing from the stacktrace :(
>
> I've now recompiled with 2.0.50 and 5.8.5 in full debug mode, and get a
> fuller stacktrace like Markus posted:
>
> Perl_safesysmalloc(unsigned int 72) line 67 + 28 bytes
> modperl_filter_new(ap_filter_t * 0x009fc490, apr_bucket_brigade *
> 0x00a28350, int 0, int 1, int 0, __int64 0) line 316 + 7 bytes
> modperl_input_filter_handler(ap_filter_t * 0x009fc490,
> apr_bucket_brigade * 0x00a28350, int 1, int 0, __int64 0) line 905 + 31
> bytes
> ap_get_brigade(ap_filter_t * 0x009fc490, apr_bucket_brigade *
> 0x00a28350, int 1, int 0, __int64 0) line 475 + 32 bytes
> net_time_filter(ap_filter_t * 0x00a282f0, apr_bucket_brigade *
> 0x00a28350, int 1, int 0, __int64 0) line 3601
> ap_get_brigade(ap_filter_t * 0x00a282f0, apr_bucket_brigade *
> 0x00a28350, int 1, int 0, __int64 0) line 475 + 32 bytes
> ap_rgetline_core(char * * 0x00a27508, unsigned int 8192, unsigned int *
> 0x04d8fed4, request_rec * 0x00a274f0, int 0, apr_bucket_brigade *
> 0x00a28350) line 215 + 27 bytes
> read_request_line(request_rec * 0x00a274f0, apr_bucket_brigade *
> 0x00a28350) line 593 + 39 bytes
> ap_read_request(conn_rec * 0x009fc138) line 886 + 13 bytes
> ap_process_http_connection(conn_rec * 0x009fc138) line 243 + 9 bytes
> ap_run_process_connection(conn_rec * 0x009fc138) line 42 + 78 bytes
> ap_process_connection(conn_rec * 0x009fc138, void * 0x009fc068) line 177
> worker_main(long 1) line 720
> _threadstartex(void * 0x0028d560) line 212 + 13 bytes
> KERNEL32! 77e7d33b()
>
> The malloc is thus from modperl_filter_new(), which says:
>
> /* we can't allocate memory from the pool here, since potentially
> * a filter can be called hundreds of times during the same
> * request/connection resulting in enormous memory demands
> * (sizeof(*filter)*number of invocations)
> */
> Newz(0, filter, 1, modperl_filter_t);
>
> I can now also see the cause of the access violation: 'my_perl' is NULL
> in Perl_safesysmalloc().
>
> Is this one of the delightful thread context problems again? Can you
> reproduce this on Linux? If its related to Win32-specific
> threads/memory games then do you still have that patch from Jan Dubois a
> while back to help you get Win32-style behaviour on Linux?
Unfortunately not, I'll need to revive it.
Any ideas why does it happen randomly?
We saw problems before when my_perl was pointing to the wrong interprter,
but never NULL.
May be we just drop safemalloc, and use the plain old malloc, or now that
we are more educated with apache internals the right solution seems to be
to create a sub-pool and use it to allocate memory. Let me try to work on
that first.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>
>>>>>>t\filter\in_bbs_inject_header.t always succeeds when run as part of
>>>>>>the whole "nmake new" run, and only sometimes crashes Apache when run
>>>>>>alone, which was only uncovered by last night's SMOKE run.
>>>>>>
>>>>>>
>
>
>
>>After numerous attempts, mine finally failed (running in isolation)
>>too.
>>
>>
>
>You mean, it's a random thing, right?
>
Yes.
>
>
>
>>Here's the stacktrace (using perl-5.8.4):
>>
>>Perl_safesysmalloc(unsigned int 268467750) line 67 + 11 bytes
>>modperl_input_filter_handler(ap_filter_t * 0x6eec8410
>>apr_pool_cleanup_null(void *), apr_bucket_brigade * 0x02b3c950, int
>>45337120, int 0, __int64 10888566729080832) line 905 + 23 bytes
>>
>>
>
>so where is that line 905? what mod_perl code has caused that malloc call?
>
That was using a release build with (some) debugging symbols. Looks
like some stuff was missing from the stacktrace :(
I've now recompiled with 2.0.50 and 5.8.5 in full debug mode, and get a
fuller stacktrace like Markus posted:
Perl_safesysmalloc(unsigned int 72) line 67 + 28 bytes
modperl_filter_new(ap_filter_t * 0x009fc490, apr_bucket_brigade *
0x00a28350, int 0, int 1, int 0, __int64 0) line 316 + 7 bytes
modperl_input_filter_handler(ap_filter_t * 0x009fc490,
apr_bucket_brigade * 0x00a28350, int 1, int 0, __int64 0) line 905 + 31
bytes
ap_get_brigade(ap_filter_t * 0x009fc490, apr_bucket_brigade *
0x00a28350, int 1, int 0, __int64 0) line 475 + 32 bytes
net_time_filter(ap_filter_t * 0x00a282f0, apr_bucket_brigade *
0x00a28350, int 1, int 0, __int64 0) line 3601
ap_get_brigade(ap_filter_t * 0x00a282f0, apr_bucket_brigade *
0x00a28350, int 1, int 0, __int64 0) line 475 + 32 bytes
ap_rgetline_core(char * * 0x00a27508, unsigned int 8192, unsigned int *
0x04d8fed4, request_rec * 0x00a274f0, int 0, apr_bucket_brigade *
0x00a28350) line 215 + 27 bytes
read_request_line(request_rec * 0x00a274f0, apr_bucket_brigade *
0x00a28350) line 593 + 39 bytes
ap_read_request(conn_rec * 0x009fc138) line 886 + 13 bytes
ap_process_http_connection(conn_rec * 0x009fc138) line 243 + 9 bytes
ap_run_process_connection(conn_rec * 0x009fc138) line 42 + 78 bytes
ap_process_connection(conn_rec * 0x009fc138, void * 0x009fc068) line 177
worker_main(long 1) line 720
_threadstartex(void * 0x0028d560) line 212 + 13 bytes
KERNEL32! 77e7d33b()
The malloc is thus from modperl_filter_new(), which says:
/* we can't allocate memory from the pool here, since potentially
* a filter can be called hundreds of times during the same
* request/connection resulting in enormous memory demands
* (sizeof(*filter)*number of invocations)
*/
Newz(0, filter, 1, modperl_filter_t);
I can now also see the cause of the access violation: 'my_perl' is NULL
in Perl_safesysmalloc().
Is this one of the delightful thread context problems again? Can you
reproduce this on Linux? If its related to Win32-specific
threads/memory games then do you still have that patch from Jan Dubois a
while back to help you get Win32-style behaviour on Linux?
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
>>>>>t\filter\in_bbs_inject_header.t always succeeds when run as part of
>>>>>the whole "nmake new" run, and only sometimes crashes Apache when run
>>>>>alone, which was only uncovered by last night's SMOKE run.
> After numerous attempts, mine finally failed (running in isolation)
> too.
You mean, it's a random thing, right?
> Here's the stacktrace (using perl-5.8.4):
>
> Perl_safesysmalloc(unsigned int 268467750) line 67 + 11 bytes
> modperl_input_filter_handler(ap_filter_t * 0x6eec8410
> apr_pool_cleanup_null(void *), apr_bucket_brigade * 0x02b3c950, int
> 45337120, int 0, __int64 10888566729080832) line 905 + 23 bytes
so where is that line 905? what mod_perl code has caused that malloc call?
> modperl_filter_add_connection(conn_rec * 0x02b3cdb0, int 0, const char *
> 0x02b3ca20, ap_filter_t * (const char *, void *, request_rec *, conn_rec
> *)* 0x00000000, const char * 0x02b3ca08) line 988 + 1 byte
> 02b3cd68()
> modperl_input_filter_handler(ap_filter_t * 0x6e6e6f63,
> apr_bucket_brigade * 0x69746365, int 1767861871, int 1953853550, __int64
> 37412188805136384) line 891
> 5f6c7265()
>
> It crashed on the line:
>
> ptr = (Malloc_t)PerlMem_malloc(size?size:1); /* malloc(0) is
> NASTY on our system */
>
> with an Access Violation exception.
>
> size is 268467750 at this point. Not sure I understand where such a
> violation is coming from.
>
> - Steve
>
>
>
> ------------------------------------------------
> Radan Computational Ltd.
>
> The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Markus Wichitill wrote:
>
>
>>Stas Bekman wrote:
>>
>>
>>
>>>>t\filter\in_bbs_inject_header.t always succeeds when run as part of
>>>>the whole "nmake new" run, and only sometimes crashes Apache when run
>>>>alone, which was only uncovered by last night's SMOKE run.
>>>>
>>>>
>Right, a debugger is needed here.
>
After numerous attempts, mine finally failed (running in isolation)
too. Here's the stacktrace (using perl-5.8.4):
Perl_safesysmalloc(unsigned int 268467750) line 67 + 11 bytes
modperl_input_filter_handler(ap_filter_t * 0x6eec8410
apr_pool_cleanup_null(void *), apr_bucket_brigade * 0x02b3c950, int
45337120, int 0, __int64 10888566729080832) line 905 + 23 bytes
modperl_filter_add_connection(conn_rec * 0x02b3cdb0, int 0, const char *
0x02b3ca20, ap_filter_t * (const char *, void *, request_rec *, conn_rec
*)* 0x00000000, const char * 0x02b3ca08) line 988 + 1 byte
02b3cd68()
modperl_input_filter_handler(ap_filter_t * 0x6e6e6f63,
apr_bucket_brigade * 0x69746365, int 1767861871, int 1953853550, __int64
37412188805136384) line 891
5f6c7265()
It crashed on the line:
ptr = (Malloc_t)PerlMem_malloc(size?size:1); /* malloc(0) is
NASTY on our system */
with an Access Violation exception.
size is 268467750 at this point. Not sure I understand where such a
violation is coming from.
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Stas Bekman <st...@stason.org>.
Markus Wichitill wrote:
> Stas Bekman wrote:
>
>>> t\filter\in_bbs_inject_header.t always succeeds when run as part of
>>> the whole "nmake new" run, and only sometimes crashes Apache when run
>>> alone, which was only uncovered by last night's SMOKE run.
>>
>>
>> So can you run:
>>
>> t/TEST -trace=debug -start
>>
>> now run:
>>
>> t/TEST -v -run t/filter/in_bbs_inject_header.t
>>
>> and post the output (client + error_log) of that last run. Thanks.
>
>
> C:\Dev\src\modperl-2.0-test>c:\dev\test\perl\bin\perl t\TEST -v -run
> t/filter/in_bbs_inject_header.t
> t\filter\in_bbs_inject_header....# connecting to localhost:8545
> 1..36
> # Running under perl version 5.008005 for MSWin32
> # Current time local: Mon Aug 16 01:51:33 2004
> # Current time GMT: Sun Aug 15 23:51:33 2004
> # Using Test.pm version 1.25
> # Using Apache/Test.pm version 1.13
> request has failed (the response code was: 500)
> see t/logs/error_log for more details
> dubious
> Test returned status 9 (wstat 2304, 0x900)
> DIED. FAILED tests 1-36
> Failed 36/36 tests, 0.00% okay
> Failed Test Stat Wstat Total Fail Failed List of
> Failed
> -------------------------------------------------------------------------------
>
> t\filter\in_bbs_inject_header.t 9 2304 36 72 200.00% 1-36
> Failed 1/1 test scripts, 0.00% okay. 36/36 subtests failed, 0.00% okay.
> [ error] error running tests (please examine t\logs\error_log)
>
> Nothing interesting in the log:
>
> [...]
> [Mon Aug 16 01:51:29 2004] [debug] child.c(684): Child 1160: Worker
> thread 49 starting.
> [eof]
Right, a debugger is needed here.
The fact is that it fails on its own but not when running after some other
tests tells me that something happens that helps the test. It's probably
not easy as there are many tests but if you do a binary search you may
find relatively quickly what specific test (or a combination of) makes it
successful. That what t/SMOKE would have done for you, but here were are
trying to find the successful sequence, not the failing one.
>> Incidently, this module does the same as this test and more:
>> http://apache.org/~stas/Apache-Filter-HTTPHeadersFixup-0.04.tar.gz
>> Could you give it a try? Make sure that you first build and install
>> the latest mod_perl cvs (i just checked it some A-T fix). Thanks.
>
>
> Crashes on t\manip\out_append.t #1, with no useful error_log either.
Good to hear that. At least the error is consistent.
The fact is that it fails on its own but not when running after some other
tests tells me that something happens that helps the test.
> Maybe we should just wait until Randy is back home, unless someone can
> give me VC6 debugging advice.
We can always exclude some tests from the release and resolve them later,
if that is not resolved by the release time.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Markus Wichitill <ma...@gmx.de>.
Stas Bekman wrote:
>> t\filter\in_bbs_inject_header.t always succeeds when run as part of
>> the whole "nmake new" run, and only sometimes crashes Apache when run
>> alone, which was only uncovered by last night's SMOKE run.
>
> So can you run:
>
> t/TEST -trace=debug -start
>
> now run:
>
> t/TEST -v -run t/filter/in_bbs_inject_header.t
>
> and post the output (client + error_log) of that last run. Thanks.
C:\Dev\src\modperl-2.0-test>c:\dev\test\perl\bin\perl t\TEST -v -run
t/filter/in_bbs_inject_header.t
t\filter\in_bbs_inject_header....# connecting to localhost:8545
1..36
# Running under perl version 5.008005 for MSWin32
# Current time local: Mon Aug 16 01:51:33 2004
# Current time GMT: Sun Aug 15 23:51:33 2004
# Using Test.pm version 1.25
# Using Apache/Test.pm version 1.13
request has failed (the response code was: 500)
see t/logs/error_log for more details
dubious
Test returned status 9 (wstat 2304, 0x900)
DIED. FAILED tests 1-36
Failed 36/36 tests, 0.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t\filter\in_bbs_inject_header.t 9 2304 36 72 200.00% 1-36
Failed 1/1 test scripts, 0.00% okay. 36/36 subtests failed, 0.00% okay.
[ error] error running tests (please examine t\logs\error_log)
Nothing interesting in the log:
[...]
[Mon Aug 16 01:51:29 2004] [debug] child.c(684): Child 1160: Worker thread
49 starting.
[eof]
> Incidently, this module does the same as this test and more:
> http://apache.org/~stas/Apache-Filter-HTTPHeadersFixup-0.04.tar.gz
> Could you give it a try? Make sure that you first build and install the
> latest mod_perl cvs (i just checked it some A-T fix). Thanks.
Crashes on t\manip\out_append.t #1, with no useful error_log either.
Maybe we should just wait until Randy is back home, unless someone can give
me VC6 debugging advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Stas Bekman <st...@stason.org>.
Markus Wichitill wrote:
> Stas Bekman wrote:
>> Do you remember the last time you run it w/o a problem? e.g. try
>> checking out earlier dates and try to find when the problem was
>> introduced.
>
>
> The weird startup errors were caused by the wrong Apache::Test version
> (as far as I can tell), that problem is history now.
Good.
> t\filter\in_bbs_inject_header.t always succeeds when run as part of the
> whole "nmake new" run, and only sometimes crashes Apache when run alone,
> which was only uncovered by last night's SMOKE run.
So can you run:
t/TEST -trace=debug -start
now run:
t/TEST -v -run t/filter/in_bbs_inject_header.t
and post the output (client + error_log) of that last run. Thanks.
Incidently, this module does the same as this test and more:
http://apache.org/~stas/Apache-Filter-HTTPHeadersFixup-0.04.tar.gz
Could you give it a try? Make sure that you first build and install the
latest mod_perl cvs (i just checked it some A-T fix). Thanks.
The above module will be released as soon as _15 is released.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Markus Wichitill <ma...@gmx.de>.
Stas Bekman wrote:
>> Ah, I just noticed that there's no "Apache-Test" directory in
>> modperl-2.0 pulled from CVS. So for my regular Apache/Perl
>> installations Apache::Test 1.13 from the Perl lib was used (probably
>> got there via an earlier snapshot?), while for the debug Apache/Perl
>> installation Apache::Test 1.12 from the Perl lib (installed from CPAN)
>> was used, which apparently caused all the weird errors. I've now
>> checked out a copy of Apache-Test in the modperl-2.0 directory.
>
> may be we should check that we have Apache-Test when building mp2, as we
> rely on having the right version to have the tests pass.
>
>> Not that it helps any. I can now run in_bbs_inject_header.t and it
>> crashes just like with the regular builds, but JIT debugging with
>> MSVC6 only shows the same useless Asm etc. as before, no useful
>> stacktrace or anything that I can see. Last time that I've used this
>> debugger was for single-threaded MFC apps, so maybe I just don't know
>> how to handle cases like this.
>
> Is it related to the failure noise you get at the server startup?
>
> Do you remember the last time you run it w/o a problem? e.g. try
> checking out earlier dates and try to find when the problem was introduced.
The weird startup errors were caused by the wrong Apache::Test version (as
far as I can tell), that problem is history now.
t\filter\in_bbs_inject_header.t always succeeds when run as part of the
whole "nmake new" run, and only sometimes crashes Apache when run alone,
which was only uncovered by last night's SMOKE run.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Markus Wichitill wrote:
>> Ah, I just noticed that there's no "Apache-Test" directory in
>> modperl-2.0 pulled from CVS. So for my regular Apache/Perl
>> installations Apache::Test 1.13 from the Perl lib was used (probably
>> got there via an earlier snapshot?), while for the debug Apache/Perl
>> installation Apache::Test 1.12 from the Perl lib (installed from CPAN)
>> was used, which apparently caused all the weird errors. I've now
>> checked out a copy of Apache-Test in the modperl-2.0 directory.
>
>
> may be we should check that we have Apache-Test when building mp2, as we
> rely on having the right version to have the tests pass.
I've just committed such check.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Stas Bekman <st...@stason.org>.
Markus Wichitill wrote:
> Randy Kobes wrote:
>
>>> C:\Dev\test\perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST
>>> -clean
>>> C:\Dev\test\perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST
>>> -bugreport -verbose=0
>>> "my" variable $script masks earlier declaration in same scope at
>>> C:\Dev\src\modperl-2.0\t\response\TestApache\subprocess.pm line 64.
>>> Compilation failed in require at
>>> C:/Dev/test/perl/site/lib/Apache/TestConfigPerl.pm line 593.
>>
>>
>> I'm not sure if this would cause this, but it's picking up
>> some modules under your installed Perl tree
>> (C:/Dev/test/perl/), rather than using that under
>> C:\Dev\src\modperl-2.0\. Perhaps there's an incompatibility?
>> Can you try moving the installed mp2/Apache-Test files away
>> while doing the tests to see if that helps?
>
>
> Ah, I just noticed that there's no "Apache-Test" directory in
> modperl-2.0 pulled from CVS. So for my regular Apache/Perl installations
> Apache::Test 1.13 from the Perl lib was used (probably got there via an
> earlier snapshot?), while for the debug Apache/Perl installation
> Apache::Test 1.12 from the Perl lib (installed from CPAN) was used,
> which apparently caused all the weird errors. I've now checked out a
> copy of Apache-Test in the modperl-2.0 directory.
may be we should check that we have Apache-Test when building mp2, as we
rely on having the right version to have the tests pass.
> Not that it helps any. I can now run in_bbs_inject_header.t and it
> crashes just like with the regular builds, but JIT debugging with MSVC6
> only shows the same useless Asm etc. as before, no useful stacktrace or
> anything that I can see. Last time that I've used this debugger was for
> single-threaded MFC apps, so maybe I just don't know how to handle cases
> like this.
Is it related to the failure noise you get at the server startup?
Do you remember the last time you run it w/o a problem? e.g. try checking
out earlier dates and try to find when the problem was introduced.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Stas Bekman <st...@stason.org>.
Markus Wichitill wrote:
> Stas Bekman wrote:
>
>>> If I check out a fresh copy of modperl-2.0 now, "Apache-Test" and
>>> "docs" are included, but "cvs up -d" on my previous working copies
>>> doesn't produce those directories. What mechanism is responsible for
>>> that?
>>
>>
>> Why did you remove those in first place? "Apache-Test" and "docs" are
>
>
> I guess I removed the directories together with everything else but
> modperl-2.0/CVS, when a while ago "nmake distclean" didn't clean enough
> after I had moved the modperl-2.0 directory from its original position.
Yeah, our distclean doesn't really clean very well. something that we need
to take care of, but may be later, unless someone will post a patch earlier :)
>> snap-on checkouts from different cvs modules. Does the following
>> explain it?
>>
>> [...]
>> apachetest-alias -d Apache-Test
>> httpd-test/perl-framework/Apache-Test
>> modperl-docs-alias -d docs modperl-docs/src/docs/2.0/
>> modperl-2.0 modperl-2.0 &apachetest-alias &modperl-docs-alias
>
>
> Yes, thanks.
Excellent.
> Now that we have cleared that up, let's move to Subversion, so we can
> have more fun with wedged BDB repositories etc. ;)
Yes, we will do that as soon as httpd-test repository moves to svn, since
as you can see we need to have Apache-Test and modperl-2.0 under the same
revision control system.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Markus Wichitill <ma...@gmx.de>.
Stas Bekman wrote:
>> If I check out a fresh copy of modperl-2.0 now, "Apache-Test" and
>> "docs" are included, but "cvs up -d" on my previous working copies
>> doesn't produce those directories. What mechanism is responsible for
>> that?
>
> Why did you remove those in first place? "Apache-Test" and "docs" are
I guess I removed the directories together with everything else but
modperl-2.0/CVS, when a while ago "nmake distclean" didn't clean enough
after I had moved the modperl-2.0 directory from its original position.
> snap-on checkouts from different cvs modules. Does the following explain
> it?
>
> [...]
> apachetest-alias -d Apache-Test
> httpd-test/perl-framework/Apache-Test
> modperl-docs-alias -d docs modperl-docs/src/docs/2.0/
> modperl-2.0 modperl-2.0 &apachetest-alias &modperl-docs-alias
Yes, thanks.
Now that we have cleared that up, let's move to Subversion, so we can have
more fun with wedged BDB repositories etc. ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Stas Bekman <st...@stason.org>.
Markus Wichitill wrote:
> Markus Wichitill wrote:
>
>> Ah, I just noticed that there's no "Apache-Test" directory in
>> modperl-2.0 pulled from CVS.
>
>
> If I check out a fresh copy of modperl-2.0 now, "Apache-Test" and "docs"
> are included, but "cvs up -d" on my previous working copies doesn't
> produce those directories. What mechanism is responsible for that?
Why did you remove those in first place? "Apache-Test" and "docs" are
snap-on checkouts from different cvs modules. Does the following explain it?
% ssh cvs.apache.org
% cat /home/cvs/CVSROOT/modules
[...]
# You can encode a module within a module by using the special '&'
# character to interpose another module into the current module. This
# can be useful for creating a module that consists of many directories
# spread out over the entire source repository.
#
[...]
apachetest-alias -d Apache-Test httpd-test/perl-framework/Apache-Test
modperl-docs-alias -d docs modperl-docs/src/docs/2.0/
modperl-2.0 modperl-2.0 &apachetest-alias &modperl-docs-alias
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Markus Wichitill <ma...@gmx.de>.
Markus Wichitill wrote:
> Ah, I just noticed that there's no "Apache-Test" directory in
> modperl-2.0 pulled from CVS.
If I check out a fresh copy of modperl-2.0 now, "Apache-Test" and "docs" are
included, but "cvs up -d" on my previous working copies doesn't produce
those directories. What mechanism is responsible for that?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Markus Wichitill <ma...@gmx.de>.
Randy Kobes wrote:
>> C:\Dev\test\perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST -clean
>> C:\Dev\test\perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST
>>-bugreport -verbose=0
>>"my" variable $script masks earlier declaration in same scope at
>>C:\Dev\src\modperl-2.0\t\response\TestApache\subprocess.pm line 64.
>>Compilation failed in require at
>>C:/Dev/test/perl/site/lib/Apache/TestConfigPerl.pm line 593.
>
> I'm not sure if this would cause this, but it's picking up
> some modules under your installed Perl tree
> (C:/Dev/test/perl/), rather than using that under
> C:\Dev\src\modperl-2.0\. Perhaps there's an incompatibility?
> Can you try moving the installed mp2/Apache-Test files away
> while doing the tests to see if that helps?
Ah, I just noticed that there's no "Apache-Test" directory in modperl-2.0
pulled from CVS. So for my regular Apache/Perl installations Apache::Test
1.13 from the Perl lib was used (probably got there via an earlier
snapshot?), while for the debug Apache/Perl installation Apache::Test 1.12
from the Perl lib (installed from CPAN) was used, which apparently caused
all the weird errors. I've now checked out a copy of Apache-Test in the
modperl-2.0 directory.
Not that it helps any. I can now run in_bbs_inject_header.t and it crashes
just like with the regular builds, but JIT debugging with MSVC6 only shows
the same useless Asm etc. as before, no useful stacktrace or anything that I
can see. Last time that I've used this debugger was for single-threaded MFC
apps, so maybe I just don't know how to handle cases like this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] t\filter\in_bbs_inject_header.t crashes when run alone
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 15 Aug 2004, Markus Wichitill wrote:
> So I finally decided to set up my own debug builds of Perl
> and Apache in addition to my normally used AS and ASF
> binaries. Compiling and installing Perl and Apache worked
> fine, however when I run "nmake test" of mod_perl CVS, the
> Apache startup fails early with the following odd error
> messages. The code pointed to by the messages looks
> perfectly fine to me.
>
> [...]
> C:\Dev\test\perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST -clean
> C:\Dev\test\perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST
> -bugreport -verbose=0
> "my" variable $script masks earlier declaration in same scope at
> C:\Dev\src\modperl-2.0\t\response\TestApache\subprocess.pm line 64.
> Compilation failed in require at
> C:/Dev/test/perl/site/lib/Apache/TestConfigPerl.pm line 593.
I'm not sure if this would cause this, but it's picking up
some modules under your installed Perl tree
(C:/Dev/test/perl/), rather than using that under
C:\Dev\src\modperl-2.0\. Perhaps there's an incompatibility?
Can you try moving the installed mp2/Apache-Test files away
while doing the tests to see if that helps?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org