Re: crash in modperl-1.24
On Wed, 16 Aug 2000, Matt Sergeant wrote: On Tue, 15 Aug 2000, Mark D. Anderson wrote: The problem was the symbol conflict between XML::Parser and apache when built with expat. This has been apparently known for over a year, but has still not been fixed last i checked, presumably because it involves 4 different products interacting: apache builds with expat, modperl gets linked in, then modperl pulls in XML::Parser which pulls in expat again. [snip] name!!! Anyway, this is a much larger problem than you expect. Not only is XML::Parser pulling in a custom non-dso expat, but so is PHP, and so is Sablotron (XSLT processor), and so is some TCL module... We need a single DSO expat that is used by everyone, but I don't have the time or resources to fix it... :-( This problem has just bitten us as well. We were building apache with expat, and then loading XML::Parser 2.29 in. Things became unstable very quickly. As a quick fix, we just disabled EXPAT from our apache builds. So I guess there is no hope of running any combination of mod_dav, XML::Parser, PHP, Sablotron at the same time at this point? Bummer :). I suppose the issue is that expat needs to be maintained and someone needs to incorporate all of hte separate patches (e.g. XML::Parser patches expat, I assume PHP/Sablotron etc are doing the same) into a single expat and create a shared library? I may be able to devote some time to this, depending on how much merging is involved. I will try to take a look at it over the next few days. Mike
Re: crash in modperl-1.24
On Thu, 28 Sep 2000, Michael J Schout wrote: On Wed, 16 Aug 2000, Matt Sergeant wrote: On Tue, 15 Aug 2000, Mark D. Anderson wrote: The problem was the symbol conflict between XML::Parser and apache when built with expat. This has been apparently known for over a year, but has still not been fixed last i checked, presumably because it involves 4 different products interacting: apache builds with expat, modperl gets linked in, then modperl pulls in XML::Parser which pulls in expat again. [snip] name!!! Anyway, this is a much larger problem than you expect. Not only is XML::Parser pulling in a custom non-dso expat, but so is PHP, and so is Sablotron (XSLT processor), and so is some TCL module... We need a single DSO expat that is used by everyone, but I don't have the time or resources to fix it... :-( This problem has just bitten us as well. We were building apache with expat, and then loading XML::Parser 2.29 in. Things became unstable very quickly. As a quick fix, we just disabled EXPAT from our apache builds. So I guess there is no hope of running any combination of mod_dav, XML::Parser, PHP, Sablotron at the same time at this point? Bummer :). I suppose the issue is that expat needs to be maintained and someone needs to incorporate all of hte separate patches (e.g. XML::Parser patches expat, I assume PHP/Sablotron etc are doing the same) into a single expat and create a shared library? I may be able to devote some time to this, depending on how much merging is involved. I will try to take a look at it over the next few days. No don't - its being done now. Clark Cooper is running the project over on source forge. However I know that Clark can be quite slow at times, so maybe he could do with some help. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: crash in modperl-1.24
On Tue, 15 Aug 2000, Mark D. Anderson wrote: (not sure whose email got delayed since i posted this question some time ago -- thanks for the tip though on how to get more meaningful modperl crash info). The problem was the symbol conflict between XML::Parser and apache when built with expat. This has been apparently known for over a year, but has still not been fixed last i checked, presumably because it involves 4 different products interacting: apache builds with expat, modperl gets linked in, then modperl pulls in XML::Parser which pulls in expat again. I rebuilt apache disabling expat and all was fine. This is so common a configuration (apache, modperl, and XML::Parser), i have to assume that the only reason there is not rioting in the streets is because perhaps it only happens the way i built it (apache statically linking modperl). I'm rioting, I'm rioting... But I don't have quite enough time to devote to it... And I wanted to register the domain name 4expat.org to try and sort this out but my ISP wants £100 a year to do dns on an extra domain name!!! Anyway, this is a much larger problem than you expect. Not only is XML::Parser pulling in a custom non-dso expat, but so is PHP, and so is Sablotron (XSLT processor), and so is some TCL module... We need a single DSO expat that is used by everyone, but I don't have the time or resources to fix it... :-( -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: crash in modperl-1.24
On Mon, 10 Jul 2000, Mark D. Anderson wrote: environment: linux redhat 2.2.12-20, modperl 1.24, apache 1.3.12 i've tried it with both perl 5.6 and with 5.005-03. in both cases, i get a segv crash almost immediately the first time i issue a request for a url using a perl handler (static file handling is fine). below are the stack traces for the two perl versions, when run with -X . any suggestions for fixes or workarounds are very appreciated. (maybe building without EVERYTHING=1? who knows) if you could do this: % gdb httpd (gdb) source mod_perl-x.xx/.gdbinit (gdb) run -X [make a request that core dumps] (gdb) curinfo should print the Perl filename:linenumber, posting a code window around that area might shed some light.
Re: crash in modperl-1.24
btw, i am using XML::Parser (2.29), and i've heard various rumors of a potential conflict with mod_perl ? but i am using the latest version of everything... -mda
