Re: Apache 1.3.9 + mod_perl 1.21 + Solaris 2.7 dumps core

[Alan Burlison <Alan.Burlison@uk.sun.com>]

Ilya Zakharevich wrote:
> 
> Alan Burlison writes:

> > The value of the ax variable in the XSUB is being set to -316718320,
> > which looks wrong to me, and causes subsequent code like the expression
> > "PL_stack_base [ ax + ( 0 ) ]" to give illegal addresses.
> >
> > ax is calculated as "mark - PL_stack_base + 1", where mark=0x6,
> > PL_stack_base=0x4fcd78.  mark is in turn calculated from "PL_stack_base
> > + ( * PL_markstack_ptr -- )", where PL_stack_base=0x4fcd78 and
> > *PL_markstack_ptr=7
> >
> > Obviously PL_markstack_ptr is bogus
> 
> Looks perfectly normal to me.
> 
>   PERLVAR(Tmarkstack_ptr,       I32 *)
> 
> It is an integer offset.

Yes, I guessed it was an offset, but it looks suspiciously negatively
large to me, and it does cause a SEGV.  Given that this is a top-level
sub call, a stack offset (ax) of -316718320 got me worried.

subsequent (macros expanded) code says this:

*PL_stack_base [ ax + ( 0 ) ]

Which points to an illegal address, hence the SEGV.  I may be barking up
the wrong tree, but at the moment it's the only tree around ;-)

Note that the SEGV only happens when Apache/perl/modperl are dynamically
linked.  Statically linked code behaves fine.  I'm wondering if the
mod_perl code goes down a different code path if it is dlopen'd rather
than being statically linked.

This is one of those horrible cases where it's not at all clear where
the problem is - Apache, perl or mod_perl.

Alan Burlison

---

Follow-Ups from:

Ilya Zakharevich <ilya@math.ohio-state.edu>

References to:

Ilya Zakharevich <ilya@math.ohio-state.edu>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---