Re: segmentation fault under mod_perl+XML::XPath
Hello, Ged and other.
Thanks for long suggestion letter. I've solved my problem with mod_perl
compiled staticaly.
GH> Hi there,
GH> Haven't seen any replies, so I thought you'd like to hear from someone. :)
Thanks...
GH> 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
GH> It's not uncommon to see XML and segfaults in the same post. :(
GH> Have you searched the archives?
Looked at it. My problem was different.
>> 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.
GH> [snip]
>> Apache - with so, unique_id, no expat
>> mod_perl with everything as DSO
GH> Whenever I see segfaults in a DSO Apache I'd say try static linking if
GH> you don't know what else to try. :)
Exactly this method is a solution.
>> Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
GH> Did you compile this Perl yourself? The standard advice is to compile
GH> mod_perl and Perl with the same compiler.
>> usemymalloc=n, bincompat5005=undef
GH> Highly unlikely, but maybe a malloc problem?
>> ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', gccosandvers=''
GH> You should be OK with that compiler, is that what you're using yourself?
GH> Hope you're not using gcc 3.x with that Perl...
I don't want to try 3.x yet.
>> Dynamic Linking:
>> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
>> cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib'
GH> Never heard of Perl (as opposed to mod_perl) dynamic linking causing a
GH> 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 ()
GH> This is the code in xmlparse.c from my 1.3.27 source tree:
GH> --
GH> static const XML_Char *poolCopyString(STRING_POOL *pool, const XML_Char *s)
GH> {
GH> do {
GH> if (!poolAppendChar(pool, *s))
GH> return 0;
GH> } while (*s++);
GH> s = pool->start;
GH> poolFinish(pool);
GH> return s;
GH> }
GH> --
GH> Assuming you're using the same thing...
GH> As far as I can see this must mean that your pointer s is invalid, and
GH> either the dereference *s causes a memory bound error or else the s++
GH> increment tries to increment it off the end of the stack or something.
GH> There's nothing else in that function that would be likely to cause the
GH> fault, if pool were invalid I'd expect it to happen in poolAppendChar().
GH> I have no idea why these might be but it's a bit serious of course.
GH> You're into XS territory, the sort of thing that can easily be thrown
GH> by struct alignment problems such as you might get on the less well
GH> exercised configurations - which probably includes FreeBSD - and an
GH> unsuitable combination of compilers/dso/libraries/...
GH> You shouldn't have to be delving this deeply into these packages, but
GH> if a static link or a compiler change doesn't fix it and you don't
GH> mind cranking gdb a bit further you could find out what that pointer
GH> is pointing to and if it's a valid XML_Char pointer.
GH> Hope this gets you started in the right direction, but please don't
GH> take it as authoritative as I've never used FreeBSD nor XML::XPath.
Big thanks for your reply.
GH> 73,
GH> Ged.
Ruslan.
Re: segmentation fault under mod_perl+XML::XPath
Hello again, On Thu, 3 Jul 2003, Ged Haywood wrote: > 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(). Of course unless poolAppendChar() turns out to be a function defined by a macro, which it does, so forget that last bit. Could be pool too. :( 73, Ged.
Re: segmentation fault under mod_perl+XML::XPath
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.
