You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Mark D. Anderson" <md...@discerning.com> on 2000/07/10 09:36:33 UTC
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=0xbffffbf4) at http_main.c:4651
#15 0x80a4e63 in main (argc=6, argv=0xbffffbf4) 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=0xbffffbf4) at http_main.c:4651
#17 0x80a1853 in main (argc=6, argv=0xbffffbf4) at http_main.c:4978
Re: [new module] Apache::PageKit
Posted by "T.J. Mather" <tj...@thoughtstore.com>.
> > Here is a brief description of the module:
> > PageKit is a set of Perl modules that provides an application
> > framework based on mod_perl and HTML::Template. It is based on the
> > Model/View/Controller approach to design, with complete seperation
> > of Perl from HTML. It includes session management, authentication, form
> > validation, sticky html forms, multiple views, modules and includes, and a
> > content management system.
>
> Can you expand on the functionality of the CMS part?
For now, the CMS part is really simple. There are links on every page to
edit the HTML template components, if the user has permission to edit.
These links link to an edit page which edits the HTML template using one
big textarea box.
What would be much cooler would be to use XML and a content editor that
would translate an XML file into HTML form elements for places in the XML
document that the user can edit. There is an interesting chapter (7) in
Open Source Linux Web Programming on this.
I am moving this discussion to pagekit-users@lists.sourceforge.net, which
is a newly created list for discussing Apache::PageKit. To subscribe, go to
http://lists.sourceforge.net/mailman/listinfo/pagekit-users
-TJ
Re: [new module] Apache::PageKit
Posted by "T.J. Mather" <tj...@thoughtstore.com>.
I got a couple of e-mails asking where this module could be found. I plan
to release the module in a few days on CPAN. I will make an announcement
on this list when I do.
-TJ Mather
Re: [new module] Apache::PageKit
Posted by Matt Sergeant <ma...@sergeant.org>.
On Tue, 15 Aug 2000, T.J. Mather wrote:
> I have an addition for the Apache/Perl Module List, under PerlHandler's
>
> PageKit cmpO Application framework w/ HTML::Template TJMATHER
>
> Here is a brief description of the module:
> PageKit is a set of Perl modules that provides an application
> framework based on mod_perl and HTML::Template. It is based on the
> Model/View/Controller approach to design, with complete seperation
> of Perl from HTML. It includes session management, authentication, form
> validation, sticky html forms, multiple views, modules and includes, and a
> content management system.
Can you expand on the functionality of the CMS part?
--
<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
[new module] Apache::PageKit
Posted by "T.J. Mather" <tj...@thoughtstore.com>.
I have an addition for the Apache/Perl Module List, under PerlHandler's
PageKit cmpO Application framework w/ HTML::Template TJMATHER
Here is a brief description of the module:
PageKit is a set of Perl modules that provides an application
framework based on mod_perl and HTML::Template. It is based on the
Model/View/Controller approach to design, with complete seperation
of Perl from HTML. It includes session management, authentication, form
validation, sticky html forms, multiple views, modules and includes, and a
content management system.
Re: crash in modperl-1.24
Posted by Matt Sergeant <ma...@sergeant.org>.
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
Posted by Michael J Schout <ms...@gkg.net>.
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
Posted by Matt Sergeant <ma...@sergeant.org>.
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
Posted by "Mark D. Anderson" <md...@discerning.com>.
(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
Posted by Doug MacEachern <do...@covalent.net>.
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.