Stas Bekman wrote:
Randy Kobes wrote:
In the light of recent changes in pools, does this make any difference to the
early startup in a vhost issue? Here is the patch again:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106166256116212&w=2
Hi Stas, Unfortunately, not. Without the above patch I got all tests to pass, but with it, I get a "free to wrong pool ..", coming from about line 1121 of perl-5.8.1/win32/vmem.h.
Oh, that's the perl pool, not apr pool ;)
Just to confirm that I have the same problem: I've taken the latest CVS, applied the above-cited patch (which adds the vhost test), and now "perl t/TEST -start" doesn't even get off the ground. I get the same "free to wrong pool" error.
I imagine you're busy now, so we can look at this later, but the problem comes in the VMem::Free() of win32/vmem.h:
aiy, that's going to be a tough one to debug remotely. I'd guess that on linux the code would be totally different. So if we can try to deduct the possible cause it'd be much better. There are a few things that could cause that, e.g. things in mod_perl.c that I'd look at:
==== /* XXX: in 5.7.2+ we can call the body of modperl_boot here * but in 5.6.1 the Perl runtime is not properly setup yet * so we have to pull this stunt to delay */ SAVEDESTRUCTOR_X(modperl_boot, 0); ==== if (!scfg->mip) { /* since mips are created after merge_server_configs() * need to point to the base mip here if this vhost * doesn't have its own */ MP_TRACE_i(MP_FUNC, "%s mip inherited from %s\n", vhost, modperl_server_desc(base_server, p)); scfg->mip = base_scfg->mip; } ====
Also anything that has to do with:
PerlOptions +Parent
So I'd follow any place that does things if MpSrvPARENT is true. I guess this is the first place to start looking it.
================================================================
void VMem::Free(void* pMem)
{
#ifdef _USE_LINKED_LIST
if (pMem) {
PMEMORY_BLOCK_HEADER ptr = (PMEMORY_BLOCK_HEADER)(((char*)pMem)-sizeof(MEMORY_BLOCK_HEADER));
if (ptr->owner != this) {
if (ptr->owner) {
#if 1
dTHX;
int *nowhere = NULL;
Perl_warn(aTHX_ "Free to wrong pool %p not %p",this,ptr->owner);
*nowhere = 0;
#else
ptr->owner->Free(pMem);
#endif
}
return;
}
GetLock();
UnlinkBlock(ptr);
ptr->owner = NULL;
m_pfree(ptr);
FreeLock();
}
#else
m_pfree(pMem);
#endif
}
================================================================
and, in the debugger, the "ptr" symbol can't be found (pMem
is). I'll try to look into this further - in the meantime,
here's a stacktrace:
=================================================================
VMem::Free(VMem * const 0x013567e8, void * 0x013464c4) line 208
PerlMemFree(IPerlMem * 0x012fe1b4, void * 0x013464c4) line 302
Perl_safesysfree(void * 0x013464c4) line 143 + 14 bytes
Perl_sv_clear(interpreter * 0x0026ee24, sv * 0x00000000) line 5197
Perl_sv_replace(interpreter * 0x0026ee24, sv * 0x008b3db8, sv * 0x0133573c) line 5048
Perl_leave_scope(interpreter * 0x0026ee24, long 290) line 695 + 11 bytes
Perl_newATTRSUB(interpreter * 0x013680f4, long 290, op * 0x0134f0b4, op * 0x00000000, op * 0x013680f4, op * 0x0134f0d4) line 4402 + 22 bytes
Perl_utilize(interpreter * 0x28029afb, int 0, long 20348780, op * 0x00000122, op * 0x00000000, op * 0x0134f270) line 3002
Perl_yyparse(interpreter * 0x2803974a) line 414 + 21 bytes
S_doeval(interpreter * 0x0134f330, int 0, op * * 0x00000000, cv * 0x00000000, unsigned long 8360) line 2802 + 6 bytes
Perl_pp_require(interpreter * 0x00901ad4) line 3298 + 58 bytes
modperl_pp_require(interpreter * 0x0026ee24) line 54 + 10 bytes
Perl_runops_standard(interpreter * 0x0026ee24) line 23 + 12 bytes
S_call_body(interpreter * 0x0026ee24, op * 0x0006f960, int 1) line 2193 + 7 bytes
Perl_eval_sv(interpreter * 0x0026ee24, sv * 0x013375e0, long 2) line 2274 + 13 bytes
modperl_require_module(interpreter * 0x0026ee24, const char * 0x011924e0, int 0) line 13 + 15 bytes
Can you please go up to this frame and lookup what module doesn't try to require? Apache::PerlSection I'd guess?
What happens if you replace that code with:
use Apache::PerlSection; $s->add_config(['<Perl >', '1;', '</Perl>']);
I'd guess that this will workaround the problem. If it's not Apache::PerlSection, see which one is that and load it before $s->add_config.
It seems to fall over at line 19 of the new t/htdocs/vhost/startup.pl -- the line "PerlModule TestVhost::basic" in $conf.
I tried adding "use TestVhost::basic" before the "$s->add_config([split /\n/, $conf]);" call, but that made no difference.
I've attached a stacktrace and the console output when running with MOD_PERL_TRACE=all (!). Hopefully you can wade through it and find something relevant?
Here's one interesting thing that I noticed when walking through it:-
We reach line 800 of Apache's server/config.c:
if ((errmsg = cmd->AP_TAKE1(parms, mconfig, w)))
Here cmf->func is modperl_cmd_modules, mconfig can't be expanded (but it's a non-NULL pointer), and w is "TestVhost::basic". We go into MP_CMD_SRV_DECLARE(modules) in mp2's src/modules/perl/modperl_cmd.c and reach line 118 which has this interesting comment above it:
/* XXX: .htaccess support cannot use this perl with threaded MPMs */ dTHXa(scfg->mip->parent->perl);
I don't understand what it means, but it's got a nasty XXX and I think the "threaded MPM" bit is relevant on Win32, isn't it? (Not that I know what that means either...)
The "arg" that modperl_require_module() is called with next is, of course, "TestVhost::basic" and it fails as you see from the stack trace.
Shot in the dark: I notice there's a Perl_safesysfree() call near the end of the stacktrace. Is it anything to do with things being run "too soon", like the trouble we had before with Perl_safesysmalloc()? (See http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-09/msg00960.html) I don't think this safesysfree() call is anything like as early as that safesysmalloc() call was, but I thought I'd bring it up just in case.
- Steve
trace.tar.gz
Description: GNU Zip compressed data
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
