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.
