Newbie question about sp_stack

Hi,

This isn't a porting question, per se, but I can't find a more appropriate
group for it.

I work for a company that uses mod_perl on its web site, and we've been
having stability problems. So I'm trying to fix the mod_perl code, but
ran across things about perl (well, libperl really) that I didn't understand.

There's this "stack_sp" global variable, which I gather points to a big
hunk of RAM that libperl can use to store stuff like variables in. There
are accessor methods "dSP", "SPAGAIN", and "PUTBACK", which define and
maintain a local copy of this global variable.

mod_perl uses these, but apparently uses them incorrectly, because
whenever stack_grow() is called (from within the EXTEND macro), something
in mod_perl keeps on using the old (freed) sp pointer.

I tried the naive approach, which was just to take out the local copy and
have the mod_perl code directly reference the stack_sp global, and that
worked *perfectly* to eliminate segfaults, because mod_perl always had
an up-to-date copy of stack_sp, but it also introduced a nasty memory leak.

Clearly, something is going on with stack_sp that I don't know about. My
guess is that the accessor functions are there for a reason; can anyone
clue me in as to what that reason is?

Are there any "obvious pitfalls" relating to stack_sp? Any places in the
code that they're used in a strange way?

FYI, we're running perl 5.004_04 (I know it's not the latest, but it's
the version that's been the least likely to segfault for us that we've
tried), with usemymalloc=n and -DSTRANGE_MALLOC (if we didn't define
STRANGE_MALLOC, bizarre things happened that purify couldn't keep
track of very well).

Thanks! And let me know if this question would be more appropriate directed
somewhere else.

	~Ben

• Newbie question about sp_stack by Ben Cottrell
• Re: Newbie question about sp_stack by Ben Cottrell
• Re: Newbie question about sp_stack by Gurusamy Sarathy
• Re: Newbie question about sp_stack by Hugo