Re: segmentation fault under mod_perl+XML::XPath

2003-07-14 Thread Ruslan U. Zakirov
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.



segmentation fault under mod_perl+XML::XPath

2003-07-05 Thread Ruslan U. Zakirov
Hello.
I've tried to use XML::XPath under mod_perl 1.27 and Apache 1.3.27, but
got segmentation fault with this peace of code:
use XML::XPath;

my $mfname='/proj/optolink/html/.meta.xml';
my $xp = XML::XPath-new(filename = $mfname);
my $ns = $xp-find('//[EMAIL PROTECTED]yes]');

Perl 5.8.0, Apache - with so, unique_id, no expat
mod_perl with everything as DSO

Under command line it's working fine and all tests during installation of
XML::XPath were fine, but the same code crush apache+mod_perl.
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x80711c5 in poolCopyString ()
(gdb) bt
#0  0x80711c5 in poolCopyString ()
#1  0x806cf71 in XML_SetBase ()
#2  0x28cfcc92 in XS_XML__Parser__Expat_SetBase ()
   from
/usr/local/lib/perl5/site_perl/5.8.0/i386-freebsd/auto/XML/Parser/Expat/Expat.so
#3  0x28c398fb in Perl_pp_entersub () from
/usr/local/libexec/apache/libperl.so
#4  0x28c33c28 in Perl_runops_standard ()
   from /usr/local/libexec/apache/libperl.so
#5  0x28bf2f36 in S_call_body () from /usr/local/libexec/apache/libperl.so
#6  0x28bf2d16 in Perl_call_sv () from
/usr/local/libexec/apache/libperl.so
#7  0x28bd3d56 in perl_call_handler ()
   from /usr/local/libexec/apache/libperl.so
#8  0x28bd359e in perl_run_stacked_handlers ()
   from /usr/local/libexec/apache/libperl.so
#9  0x28bd1d64 in perl_handler () from
/usr/local/libexec/apache/libperl.so
#10 0x8052595 in ap_invoke_handler ()
#11 0x806225c in process_request_internal ()
#12 0x80622bd in ap_process_request ()
#13 0x805b52e in child_main ()
#14 0x805b6a0 in make_child ()
#15 0x805b7bd in startup_children ()
#16 0x805bcb4 in standalone_main ()
#17 0x805c397 in main ()
#18 0x804ebe1 in _start ()

Any help would be good.
Ruslan.




segmentation fault under mod_perl+XML::XPath

2003-07-02 Thread Ruslan U. Zakirov
Hello.
I've tried to use XML::XPath under mod_perl 1.27 and Apache 1.3.27, but
got segmentation fault with this peace of code:
use XML::XPath;

my $mfname='/proj/optolink/html/.meta.xml';
my $xp = XML::XPath-new(filename = $mfname);
my $ns = $xp-find('//[EMAIL PROTECTED]yes]');

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.



Apache - with so, unique_id, no expat
mod_perl with everything as DSO

Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
  Platform:
osname=freebsd, osvers=4.5-stable, archname=i386-freebsd
uname='freebsd flamengo.citl.miee.ru 4.5-stable freebsd 4.5-stable #3: tue apr 23 
15:48:51 msd 2002 [EMAIL PROTECTED]:usrsrcsyscompileflamengo i386 '
config_args='-de'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
  Compiler:
cc='cc', ccflags ='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing 
-I/usr/local/include',
optimize='-O',
cppflags='-DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing 
-I/usr/local/include'
ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
  Linker and Libraries:
ld='cc', ldflags ='-Wl,-E  -L/usr/local/lib'
libpth=/usr/lib /usr/local/lib
libs=-lm -lc -lcrypt -lutil
perllibs=-lm -lc -lcrypt -lutil
libc=, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version=''
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-DPIC -fpic', lddlflags='-shared  -L/usr/local/lib'


Characteristics of this binary (from libperl):
  Compile-time options: USE_LARGE_FILES
  Built under freebsd
  Compiled at Oct 23 2002 11:00:00
  @INC:
/usr/local/lib/perl5/5.8.0/i386-freebsd
/usr/local/lib/perl5/5.8.0
/usr/local/lib/perl5/site_perl/5.8.0/i386-freebsd
/usr/local/lib/perl5/site_perl/5.8.0
/usr/local/lib/perl5/site_perl


Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x80711c5 in poolCopyString ()
(gdb) bt
#0  0x80711c5 in poolCopyString ()
#1  0x806cf71 in XML_SetBase ()
#2  0x28cfcc92 in XS_XML__Parser__Expat_SetBase ()
   from
/usr/local/lib/perl5/site_perl/5.8.0/i386-freebsd/auto/XML/Parser/Expat/Expat.so
#3  0x28c398fb in Perl_pp_entersub () from
/usr/local/libexec/apache/libperl.so
#4  0x28c33c28 in Perl_runops_standard ()
   from /usr/local/libexec/apache/libperl.so
#5  0x28bf2f36 in S_call_body () from /usr/local/libexec/apache/libperl.so
#6  0x28bf2d16 in Perl_call_sv () from
/usr/local/libexec/apache/libperl.so
#7  0x28bd3d56 in perl_call_handler ()
   from /usr/local/libexec/apache/libperl.so
#8  0x28bd359e in perl_run_stacked_handlers ()
   from /usr/local/libexec/apache/libperl.so
#9  0x28bd1d64 in perl_handler () from
/usr/local/libexec/apache/libperl.so
#10 0x8052595 in ap_invoke_handler ()
#11 0x806225c in process_request_internal ()
#12 0x80622bd in ap_process_request ()
#13 0x805b52e in child_main ()
#14 0x805b6a0 in make_child ()
#15 0x805b7bd in startup_children ()
#16 0x805bcb4 in standalone_main ()
#17 0x805c397 in main ()
#18 0x804ebe1 in _start ()

Any help would be good.
Ruslan.



Re: segmentation fault under mod_perl+XML::XPath

2003-07-02 Thread Ged Haywood
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.



Re: segmentation fault under mod_perl+XML::XPath

2003-07-02 Thread Ged Haywood
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.