On Mon, 31 Mar 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> > - secondly, there's a problem in starting the tests, with a free
> > to a wrong pool and then an access violation in the perl58 lib.
>
> I've just built the worker on linux, but haven't seen any problems.
>
> I think the only change in that area was a move of mips
> intialization to an earlier stage, before any modules or files
> are required.
Below is a trace from building with MP_DEBUG on - I haven't
yet built a debug Perl, but before doing that, I'm wondering
if this is enough to point to the problem:
================================================================
PERL58! 28083437()
PERL58! 2800d128()
PERL58! 28066d46()
PERL58! 28066b87()
PERL58! 28066bd8()
modperl_ptr2obj(interpreter * 0x0089a78c, char * 0x00c15d50 `string', void *
0x0006f7ec) line 162 + 21 bytes
modperl_handler_make_args(interpreter * 0x0089a78c, av * * 0x0006f748) line 167 + 17
bytes
modperl_cmd_perldo(cmd_parms_struct * 0x0006f7ec, void * 0x00854810, const char *
0x013b7548) line 394 + 33 bytes
invoke_cmd(const command_struct * 0x6ff02358, cmd_parms_struct * 0x00c10110, void *
0x0006f7ec, const char * 0x00854810) line 713 + 14 bytes
ap_walk_config_sub(const ap_directive_t * 0x6ff022d5, cmd_parms_struct * 0x013b7488,
ap_conf_vector_t * 0x0006f7ec) line 1082 + 12 bytes
ap_walk_config(ap_directive_t * 0x00bf7014, cmd_parms_struct * 0x013b7488,
ap_conf_vector_t * 0x0006f7ec) line 1121 + 11 bytes
modperl_config_insert(interpreter * 0x0143854c, server_rec * 0x0082c398, apr_pool_t *
0x0026a838, apr_pool_t * 0x00000000, int 150, char * 0x00000000, ap_conf_vector_t *
0x0082c960, sv * 0x015ebe34) line 433 + 18 bytes
modperl_config_insert_server(interpreter * 0x0143854c, server_rec * 0x0082c398, sv *
0x015ebe34) line 451 + 36 bytes
XS_Apache__Server_add_config(interpreter * 0x0143854c, cv * 0x015d4624) line 99 + 17
bytes
PERL58! 2803f717()
PERL58! 2805d726()
PERL58! 28026f94()
PERL58! 2801e5df()
PERL58! 2802889a()
======================================================================
modperl_handler_make_args(interpreter *, av **) in
modperl_handler.c calls
sv = modperl_ptr2obj(aTHX_ classname, ptr);
with the values:
+ classname 0x00c15d50 "Apache::CmdParms"
ptr 0x0006f7ec
+ sv 0x013c0aec
========================================================================
while modperl_ptr2obj(pTHX_ char *classname, void *ptr) in
modperl_util.c calls
sv_setref_pv(sv, classname, ptr);
with values
+ classname 0x00c15d50 "Apache::CmdParms"
ptr 0x0006f7ec
+ sv 0x0143e514
======================================================================
That last call to sv_setref_pv(sv, classname, ptr) seems
to be where things stop - the last message from enabling
PerlTrace All in httpd.conf is
sv_setref_pv(Apache::CmdParms, something)
which I think is coming from the call to
MP_TRACE_h(MP_FUNC, "sv_setref_pv(....)", ....);
within modperl_ptr2obj(...) of modperl_util.c.
After that, there's a message about a free to a wrong pool.
I don't really understand the details of all this, but
might a problem be that, in the call
sv = modperl_ptr2obj(aTHX_ classname, ptr);
in modperl_handler_make_args(...) in modperl_handler.c, the
value of "sv" (0x013c0aec) isn't the same as that
(0x0143e514) found in modperl_ptr2obj(...) in
modperl_util.c? In any event, is there anything I could
do to try to track this down? If this isn't enough, would
building against a debug Perl help? Thanks.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
