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. -- 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 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 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... :-( -- 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
(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). -mda
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
crash in modperl-1.24
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) -mda 0x8123195 in Perl_sv_setsv () (gdb) whe #0 0x8123195 in Perl_sv_setsv () #1 0x811a333 in Perl_pp_sassign () #2 0x8119fbd in Perl_runops_standard () #3 0x80e2055 in S_call_body () #4 0x80e1e1e in perl_call_sv () #5 0x807ebbb in perl_call_handler (sv=0x8329db8, r=0x85360bc, args=0x0) at mod_perl.c:1643 #6 0x807e3cb in perl_run_stacked_handlers (hook=0x815cbf9 "PerlHandler", r=0x85360bc, handlers=0x832a04c) at mod_perl.c:1362 #7 0x807c99d in perl_handler (r=0x85360bc) at mod_perl.c:905 #8 0x8098eb3 in ap_invoke_handler (r=0x85360bc) at http_config.c:508 #9 0x80ac479 in process_request_internal (r=0x85360bc) at http_request.c:1215 #10 0x80ac4dc in ap_process_request (r=0x85360bc) at http_request.c:1231 #11 0x80a3dbe in child_main (child_num_arg=0) at http_main.c:4177 #12 0x80a3f4c in make_child (s=0x8192bbc, slot=0, now=963211804) at http_main.c:4281 #13 0x80a40a9 in startup_children (number_to_start=5) at http_main.c:4363 #14 0x80a46d6 in standalone_main (argc=6, argv=0xbbf4) at http_main.c:4651 #15 0x80a4e63 in main (argc=6, argv=0xbbf4) at http_main.c:4978 (gdb) Program received signal SIGSEGV, Segmentation fault. 0x8102050 in Perl_pp_rv2hv () (gdb) whe #0 0x8102050 in Perl_pp_rv2hv () #1 0x812f25d in Perl_runops_standard () #2 0x811b5bb in sortcv () #3 0x811f8cf in qsortsv () #4 0x8119e66 in Perl_pp_sort () #5 0x812f25d in Perl_runops_standard () #6 0x80d76a1 in perl_call_sv () #7 0x807ca6b in perl_call_handler (sv=0x81f3850, r=0x84dce6c, args=0x0) at mod_perl.c:1643 #8 0x807c27b in perl_run_stacked_handlers (hook=0x8134b19 "PerlHandler", r=0x84dce6c, handlers=0x84c192c) at mod_perl.c:1362 #9 0x807a7fd in perl_handler (r=0x84dce6c) at mod_perl.c:905 #10 0x8095983 in ap_invoke_handler (r=0x84dce6c) at http_config.c:508 #11 0x80a8e69 in process_request_internal (r=0x84dce6c) at http_request.c:1215 #12 0x80a8ecc in ap_process_request (r=0x84dce6c) at http_request.c:1231 #13 0x80a07ae in child_main (child_num_arg=0) at http_main.c:4177 #14 0x80a093c in make_child (s=0x816a9ec, slot=0, now=963213899) at http_main.c:4281 #15 0x80a0a99 in startup_children (number_to_start=5) at http_main.c:4363 #16 0x80a10c6 in standalone_main (argc=6, argv=0xbbf4) at http_main.c:4651 #17 0x80a1853 in main (argc=6, argv=0xbbf4) at http_main.c:4978
