Hi there,
Haven't seen any replies, so I thought you'd like to hear from someone. :)
On Wed, 2 Jul 2003, Ruslan U. Zakirov wrote:
> I've tried to use XML::XPath under mod_perl 1.27 and Apache 1.3.27, but
> got segmentation fault
It's not uncommon to see XML and segfaults in the same post. :(
Have you searched the archives?
> Under command line and CGI it's working fine and all tests during installation of
> XML::XPath were fine, but the same code crush apache+mod_perl.
[snip]
> Apache - with so, unique_id, no expat
> mod_perl with everything as DSO
Whenever I see segfaults in a DSO Apache I'd say try static linking if
you don't know what else to try. :)
> Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Did you compile this Perl yourself? The standard advice is to compile
mod_perl and Perl with the same compiler.
> usemymalloc=n, bincompat5005=undef
Highly unlikely, but maybe a malloc problem?
> ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', gccosandvers=''
You should be OK with that compiler, is that what you're using yourself?
Hope you're not using gcc 3.x with that Perl...
> Dynamic Linking:
> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
> cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib'
Never heard of Perl (as opposed to mod_perl) dynamic linking causing a
problem, so don't worry about that. (Until later.:)
> Backtrace:
> Program received signal SIGSEGV, Segmentation fault.
> 0x80711c5 in poolCopyString ()
> (gdb) bt
> #0 0x80711c5 in poolCopyString ()
This is the code in xmlparse.c from my 1.3.27 source tree:
----------------------------------------------------------------------
static const XML_Char *poolCopyString(STRING_POOL *pool, const XML_Char *s)
{
do {
if (!poolAppendChar(pool, *s))
return 0;
} while (*s++);
s = pool->start;
poolFinish(pool);
return s;
}
----------------------------------------------------------------------
Assuming you're using the same thing...
As far as I can see this must mean that your pointer s is invalid, and
either the dereference *s causes a memory bound error or else the s++
increment tries to increment it off the end of the stack or something.
There's nothing else in that function that would be likely to cause the
fault, if pool were invalid I'd expect it to happen in poolAppendChar().
I have no idea why these might be but it's a bit serious of course.
You're into XS territory, the sort of thing that can easily be thrown
by struct alignment problems such as you might get on the less well
exercised configurations - which probably includes FreeBSD - and an
unsuitable combination of compilers/dso/libraries/...
You shouldn't have to be delving this deeply into these packages, but
if a static link or a compiler change doesn't fix it and you don't
mind cranking gdb a bit further you could find out what that pointer
is pointing to and if it's a valid XML_Char pointer.
Hope this gets you started in the right direction, but please don't
take it as authoritative as I've never used FreeBSD nor XML::XPath.
73,
Ged.
