Unexplained segfault with XML::XPath (not FAQ)

[br...@dss.state.va.us]

I've got some code that segfaults without explanation.  It's an
XML::XPath call that kills it, but I'm running mod_perl/1.26 so the
XML::Parser bug shouldn't be there.  (Also, it was working previously,
though I'm not aware of what triggered the change)

Embedded Perl version v5.6.1 for Apache/1.3.22 (Unix) (Red-Hat/Linux)
mod_perl/1.26

Relevant code:

my $xp = XML::XPath->new(xml => $xml);
#gets here without troubles
my $nodeset = $xp->find('/Dcsecase/Transaction/MPI');
#doesn't get here.

I've tried this block of code in a simple script outside of Apache with
the same XML and it works flawlessly.

Any ideas?

Re: Unexplained segfault with XML::XPath (not FAQ)

[Kip Hampton <kh...@totalcinema.com>]

brs900@dss.state.va.us wrote:
> I've got some code that segfaults without explanation.  It's an
> XML::XPath call that kills it, but I'm running mod_perl/1.26 so the
> XML::Parser bug shouldn't be there.  (Also, it was working previously,
> though I'm not aware of what triggered the change)

Not sure what might've caused the change either, but for what its worth, 
the Apache-Expat bug doesn't really have anything to do with mod_perl 
but Apache itself, and IIRC, 1.3.22 was one of the offending versions.

You can verify by executing

strings /path/to/your/apache/bin/httpd | grep -i XML.

If there are any results at all, then you have an Apache with expat 
compiled in and you either need to recompile, or, better, get a more 
recent version.

If that doesn't expose/fix the problem, try starting httpd in 
single-server mode in gdb and requesting the offending script until it 
segfaults and generating a backtrace

gdb /path/to/your/apache/httpd
run -X
# request until it goes boom
bt

This will give you a backtrace that should show the culprit.

-kip