Versions:
FreeBSD 4.2-STABLE
Apache 1.3.17
mod_perl 1.25
perl 5.00503
XML::Parser 2.30
expat 1.95.1
opensrs-client 2.3.2
When used under mod_perl in the environment described, a call to the parse() method in an
XML::Parser object causes the Apache instance to segfault. This is in context of the OpenSRS
client communication library, which uses XML for its protocol. Everything is fine when the same
code is used as a standalone CGI.
Logged In: YES
user_id=3066
I *think* you're getting two copies of Expat linked in, but I'm not sure. Essentially, Apache/mod_perl might have one, and XML::Parser can also have one.
I'm assigning this to Clark since the Perl bindings are his baby.
Logged In: YES
user_id=202926
I have the same problem on a solaris box. I think fdrake has
made a correct diagnosis. Apache contains 'expat-lite' and
there seems to be a namespace collision when you load expate
via Perl::XML under mod_perl.
I am not sure what the solution is.
--randy wright
rw26@acf3.nyu.edu
Logged In: YES
user_id=212228
I ran into this same problem on Linux. By compiling Apache
without expat, parse() now runs fine in XML::Parser. I ran
Apache's configure with the
--disable-rule=EXPAT
option.
Of course, the implicit assumption here is that other parts
of Apache are OK not having expat-lite installed.....
Logged In: YES
user_id=352037
This bug has been fixed in apache 1.3.21, since this release
apache is built using the local expat libraries, if they are
present, instead of apaches in-built libraries. I have
tested apache 1.3.22, with expat 1.95.2 and mod_perl 1.26
and it appears to work fine.
Logged In: YES
user_id=3066
Closing this as "fixed as well as possible"; it's not really
an Expat bug but an issue of controlling runtime link
conflicts. There's nothing more for Expat to do.