use XML::XPath;
my $xp = XML::XPath->new(xml => "<?xml version=\"1.0\" encoding=\"UTF-8\" ?><config><name>Foo</name></config>");
my $res = $xp->getNodeText("/config/name");
That segfaults my apache every time, but works find when run on the command line.
This seems to be come from libexpat, and here is the gdb backtrace:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 20556)] 0x4022e245 in memmove () from /lib/libc.so.6 (gdb) bt #0 0x4022e245 in memmove () from /lib/libc.so.6 #1 0x080e9772 in XML_GetBuffer () #2 0x080e95c0 in XML_Parse () #3 0x4036fe9d in XS_XML__Parser__Expat_ParseString () from /usr/local/lib/perl/5.8.2/auto/XML/Parser/Expat/Expat.so <snip>
Valgrind's output:
==20558== Invalid write of size 4
==20558== at 0x4042A245: memmove (in /lib/libc-2.3.2.so)
==20558== by 0x80E9771: XML_GetBuffer (in /usr/local/apache/bin/httpd)
==20558== by 0x80E95BF: XML_Parse (in /usr/local/apache/bin/httpd)
==20558== by 0x423D9E9C: XS_XML__Parser__Expat_ParseString (in /usr/local/lib/perl/5.8.2/auto/XML/Parser/Expat/Expat.so)
==20558== Address 0x0 is not stack'd, malloc'd or free'd
==20558==
==20558== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==20558== Address not mapped to object at address 0x0
==20558== at 0x4042A245: memmove (in /lib/libc-2.3.2.so)
==20558== by 0x80E9771: XML_GetBuffer (in /usr/local/apache/bin/httpd)
==20558== by 0x80E95BF: XML_Parse (in /usr/local/apache/bin/httpd)
==20558== by 0x423D9E9C: XS_XML__Parser__Expat_ParseString (in /usr/local/lib/perl/5.8.2/auto/XML/Parser/Expat/Expat.so)
I wrote a quick C program that did similar stuff w/libexpat (giving it an XML string to parse), and had no problems.
I'll happily do any legwork, or give any other needed information.
Cory 'G' Watson
"The universal aptitude for ineptitude makes any human accomplishment an incredible miracle." - Dr. John Paul Stapp
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html