Steve Hay wrote: [...]
OK, here's another short conf file which does now break again:
===== LoadModule perl_module C:\Temp\modperl-2.0\src\modules\perl\mod_perl.so ServerName localhost:8529 Listen 8529 ServerRoot C:/Temp/modperl-2.0/t DocumentRoot C:/Temp/modperl-2.0/t/htdocs LogLevel debug Listen 8530 <VirtualHost _default_:8530> PerlOptions +Parent PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib PerlSwitches -IC:/Temp/modperl-2.0/blib/lib PerlSwitches -IC:/Temp/modperl-2.0/blib/arch PerlSwitches -IC:/Temp/modperl-2.0/t/response PerlModule Apache::ServerUtil <Perl> my $s = Apache->server; $s->add_config(['PerlModule TestVhost::basic']); </Perl> </VirtualHost> =====
The add_config() call there is taken from the t/htdocs/vhost/startup.pl, part of the vhost test patch that still breaks. Note that the above conf breaks (in the usual way) with seemingly *any* module in place of TestVhost::basic -- I tried Apache, File::Spec, CGI, DBI and a few others and they all broke.
I'm testing with the latest CVS, plus the first of Stas' recent patches (the one here: http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=107465681330157&w=2).
With the above conf file, the following "-t" command-line fails with the good ol' "free to wrong pool" error:
C:\apache2\bin\Apache.exe -t -d C:/Temp/modperl-2.0/t -f C:/Temp/modperl-2.0/t/conf/httpd.conf.short3 -DAPACHE2 -DPERL_USEITHREADS
It can be "fixed" by just commenting-out the add_config() call in the <Perl> section. (Indeed, without that add_config() call the server can be started up for real without the "-t" option.)
Thanks Steve, how about this config. I bet it breaks just the same.
....
<VirtualHost _default_:8530>
PerlOptions +Parent
PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib
PerlSwitches -IC:/Temp/modperl-2.0/blib/lib
PerlSwitches -IC:/Temp/modperl-2.0/blib/arch
PerlSwitches -IC:/Temp/modperl-2.0/t/response
PerlModule Apache::ServerUtil
<Perl>
use Apache::ServerUtil;
use Apache::Log;
my $s = Apache->server;
$s->log_error('Trulala');
</Perl>
</VirtualHost>And what about this:
....
<VirtualHost _default_:8530>
PerlOptions +Parent
PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib
PerlSwitches -IC:/Temp/modperl-2.0/blib/lib
PerlSwitches -IC:/Temp/modperl-2.0/blib/arch
PerlSwitches -IC:/Temp/modperl-2.0/t/response
PerlModule Apache::ServerUtil
<Perl>
use Apache::Log;
Apache::warn("Oh la la");
</Perl>
</VirtualHost>Here's a stacktrace of the failure:
Thanks
BTW, if you've read my request to p5p, I don't think the perl_destruct traces (on the infamous error) are of any good use. Since they just tell that there is a problem, but they don't say where. winFU-perl needs to spot the problem when it's created and not when the perl exits. So as you could see from my last patch, restoring the context fixes some things. So ideally i want winFU-perl pin-point that place in the code where the context was wrong.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
