Seg Fault Issues- mod_perl and XML::Parser
Hi-- Having a problem with modperl/xml-parser. I have been encountering mysterious segfault errors in apache child processes when it is under load, and I am trying to narrow down what is happening. replacing the die statements from Parser.pm helped get rid of alot of the segs, but this issue still crops up periodically. i also made sure that apache compiled with Expat=no. I have included the most common stacktrace from gbd below (i have several others). All seem to be related to expat, but i can't tell exactly what is breaking from the trace. Any help deciphering the trace would be greatly appreciated! Also, I would like to use this trick so that I can get more info on mod perl-- (gdb) source modperl_x.xx/.gdbinit (gdb) curinfo Do I need to re-compile perl with DEBUG for this to work? Also, i can't seem to find .gdbinit-- don't know if this will help this problem in any case, but would like to at least have this in the tool chest. I am working with: mod perl 1.23 linux 6.2 apache 1.39 XML::Parser 2.29 Program received signal SIGSEGV, Segmentation fault. 0x8118fc5 in Perl_sv_setsv () (gdb) bt #0 0x8118fc5 in Perl_sv_setsv () #1 0x8110bb3 in Perl_pp_sassign () #2 0x811083d in Perl_runops_standard () #3 0x8131dce in Perl_pp_exit () #4 0x8131e45 in Perl_pp_exit () #5 0x8133dfc in Perl_pp_entertry () #6 0x811083d in Perl_runops_standard () #7 0x80d88d5 in perl_call_sv () #8 0x80d8494 in perl_call_sv () #9 0x402e8e76 in endElement () from /usr/local/lib/perl5/site_perl/5.6.0/i686-linux/auto/XML/Parser/Expat/Expat.so #10 0x80c03e6 in XML_ErrorString () #11 0x80bf559 in XML_ErrorString () #12 0x80c1ddb in XML_ErrorString () #13 0x80c1b12 in XML_ErrorString () #14 0x80bf0f2 in XML_ParseBuffer () #15 0x402e877f in parse_stream () from /usr/local/lib/perl5/site_perl/5.6.0/i686-linux/auto/XML/Parser/Expat/Expat.so #16 0x402ebd16 in XS_XML__Parser__Expat_ParseStream () from /usr/local/lib/perl5/site_perl/5.6.0/i686-linux/auto/XML/Parser/Expat/Expat.so #17 0x81157a5 in Perl_pp_entersub () #18 0x811083d in Perl_runops_standard () #19 0x8131dce in Perl_pp_exit () #20 0x8131e45 in Perl_pp_exit () #21 0x8133dfc in Perl_pp_entertry () #22 0x811083d in Perl_runops_standard () #23 0x80d88d5 in perl_call_sv () #24 0x80d8494 in perl_call_sv () #25 0x402e8e76 in endElement () from /usr/local/lib/perl5/site_perl/5.6.0/i686-linux/auto/XML/Parser/Expat/Expat.so #26 0x80c03e6 in XML_ErrorString () #27 0x80bf559 in XML_ErrorString () #28 0x80c1ddb in XML_ErrorString () #29 0x80c1b12 in XML_ErrorString () #30 0x80bf0f2 in XML_ParseBuffer () #31 0x402e877f in parse_stream () from /usr/local/lib/perl5/site_perl/5.6.0/i686-linux/auto/XML/Parser/Expat/Expat.so #32 0x402ebd16 in XS_XML__Parser__Expat_ParseStream () from /usr/local/lib/perl5/site_perl/5.6.0/i686-linux/auto/XML/Parser/Expat/Expat.so #33 0x81157a5 in Perl_pp_entersub () #34 0x811083d in Perl_runops_standard () #35 0x8131dce in Perl_pp_exit () #36 0x8131e45 in Perl_pp_exit () #37 0x8133dfc in Perl_pp_entertry () #38 0x811083d in Perl_runops_standard () #39 0x80d88d5 in perl_call_sv () #40 0x80d8494 in perl_call_sv () #41 0x402e8e76 in endElement () from /usr/local/lib/perl5/site_perl/5.6.0/i686-linux/auto/XML/Parser/Expat/Expat.so #42 0x80c01df in XML_ErrorString () #43 0x80bf559 in XML_ErrorString () #44 0x80c1ddb in XML_ErrorString () #45 0x80c1b12 in XML_ErrorString () #46 0x80bf0f2 in XML_ParseBuffer () #47 0x402e877f in parse_stream () from /usr/local/lib/perl5/site_perl/5.6.0/i686-linux/auto/XML/Parser/Expat/Expat.so #48 0x402ebd16 in XS_XML__Parser__Expat_ParseStream () from /usr/local/lib/perl5/site_perl/5.6.0/i686-linux/auto/XML/Parser/Expat/Expat.so #49 0x81157a5 in Perl_pp_entersub () #50 0x811083d in Perl_runops_standard () #51 0x80d88d5 in perl_call_sv () #52 0x80d869e in perl_call_sv () #53 0x807ca7b in perl_call_handler () #54 0x807c426 in perl_run_stacked_handlers () #55 0x807b17d in perl_handler () #56 0x8096093 in ap_invoke_handler () #57 0x80a9469 in ap_some_auth_required () #58 0x80a94cc in ap_process_request () #59 0x80a0e8e in ap_child_terminate () #60 0x80a101c in ap_child_terminate () #61 0x80a1179 in ap_child_terminate () #62 0x80a17a6 in ap_child_terminate () #63 0x80a1f23 in main () #64 0x400a81eb in __libc_start_main (main=0x80a1bec , argc=2, argv=0xbcd4, init=0x80627f0 <_init>, fini=0x814dc9c <_fini>, rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xbccc) at ../sysdeps/generic/libc-start.c:90
Re: Seg Fault Issues- mod_perl and XML::Parser
Matt-- I wish it were this easy to fix. I don't think i have a conflict with mod_dav (i never installed mod_dav)- never installed another conflicting expat- and I already compiled with Expat=no. Maybe i missed something, but I think there is some other problem here. Tom At 08:09 PM 11/1/00 +, Matt Sergeant wrote: >On Wed, 1 Nov 2000, Tom Harper wrote: > >> Hi-- >> >> Having a problem with modperl/xml-parser. > >Aren't we all :-) > >Try http://axkit.org/faq.xml > >Also, there is a patch for this (finally!) in http://axkit.org/download/ - >the mod_dav-shared-expat patch. I've sent this to Greg Stein (but not >heard any response yet). > >-- > > >/||** Director and CTO ** > //||** AxKit.com Ltd ** ** XML Application Serving ** > // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** > // \\| // ** Personal Web Site: http://sergeant.org/ ** > \\// > //\\ >// \\ >
Re: Seg Fault Issues- mod_perl and XML::Parser
Hi-- In case anyone encounters the same segv issues, recompiled apache with mod_perl 1.24-- explicitly set Rule EXPAT=no rather than Rule EXPAT=default in the apache_base/src/Configure. No more segv. Then i recompiled again with mod_perl 1.23. Again, no more segv. Go figure. Anyhow, based on this experience we are very enthusiastic about XML::Parser package. We are mis-using XML::Parser as part of a X(HT)ML based templating engine, and since the fix it has handled significant load without complaint (>50 concurrent connections). Tom At 08:09 PM 11/1/00 +, Matt Sergeant wrote: >On Wed, 1 Nov 2000, Tom Harper wrote: > >> Hi-- >> >> Having a problem with modperl/xml-parser. > >Aren't we all :-) > >Try http://axkit.org/faq.xml > >Also, there is a patch for this (finally!) in http://axkit.org/download/ - >the mod_dav-shared-expat patch. I've sent this to Greg Stein (but not >heard any response yet). > >-- > > >/||** Director and CTO ** > //||** AxKit.com Ltd ** ** XML Application Serving ** > // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** > // \\| // ** Personal Web Site: http://sergeant.org/ ** > \\// > //\\ >// \\ >
Re: how do I store/retrieve a hash through Apache::Session?
Enrique--
You need to store/retrieve it as a ref-
\%my_hash
Tom
At 04:36 PM 11/3/00 +, Enrique I.Rodriguez wrote:
>Maybe a silly question...
>
>how do I store/retrieve a hash through Apache::Session?
>
>This doesn't work...
># retrieve
>%table=$session{table};
>...
># store
>$session{table}=%table;
>
>What's my fault?
>
Child Process Expiration ( Was RE: Memory Usage)
Hi Folks-- This may be slightly off topic, but I suppose adds to the prior discussion-- G.W. Haywood (i think?) said that he set child process expiration at 100 hits-- this seems small to me, mostly because the 1.3.9 apache distribution notes (which claims that 10,000 is high), and partly because throttling at 1000 has seemed to work (so far) for me... was wondering what other folks set their child process expiration at for best performance with mod-perl (and why) ? Any wisdom would be helpful, Tom At 06:22 PM 11/7/00 -0600, Christian Gilmore wrote: >Find attached the rotatelogs.pl script. My experience is that killing off >children after so much usage is a GoodThing (tm). So long as the parent >remains at a stable size, things should go ok. > >Regards, >Christian > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]]On Behalf >> Of Buddy Lee Haystack >> Sent: Tuesday, November 07, 2000 3:27 PM >> To: Christian Gilmore >> Cc: 'G.W. Haywood'; 'mod_perl list' >> Subject: Re: Memory Usage >> >> >> Thanks Christian! >> >> Scripts would be nice.;-) >> >> I take it you've used DSO much more than I have, so I'm >> interested in any information in addition to that provided by >> the kind "G.W. Haywood" to the following: >> >> "What concerns me even more is the fact that I have Apache >> restart child processes after they each serve 100 requests >> [MaxRequestsPerChild 100] it's a RedHat default that is >> supposed to reduce memory leaks, but with mod_perl & DSO it >> may actually have the opposite effect. I can easily increase >> the value, or remove it altogether. Any recommendations?" >> >> >> Christian Gilmore wrote: >> > >> > > I'm leaning along the lines of just killing the >> > > process, rotating the logs, and restarting it. It should take >> > > no more than 5 seconds once a week a 4:00am. >> > >> > This is exactly what I do, except I have it scripted. The >> downside is that >> > your service is unavailable for a few seconds (maybe more >> depending upon >> > the length of time it takes for the parent to wipe out all the old >> > children). I'd be happy to share the script, provided my >> boss doesn't >> > mind. :) >> > >> > Regards, >> > Christian >> >> -- >> BLH >> www.RentZone.org >> > > >Attachment Converted: "d:\eudora\attach\rotatelogs.pl" >
IPC Linux -- WAS [Re: mod_perl & IPC under Solaris 7]
I have been looking for where I can set this setting in (redhat) linux-- anyone have any pointers? ipcs, ipcrm are there, but i don't have an etc/system. very little documentation on this for linux (or bsd) that i could find. Tom At 06:29 PM 12/8/00 +0100, Steven Cotton wrote: >On Fri, 8 Dec 2000, Mark Doyle wrote: > >> I suppose the first place to look is to use the Solaris >> commands ipcs and ipcrm... Also, I believe you have to >> update the kernerl parameters for shared memory. The default >> is pretty skimpy. Look at adding things like: >> >> to /etc/system. > >Yes, I have made some changes there. I have: > >set shmsys:shminfo_shmmax = 8388608 >set shmsys:shminfo_shmmni = 10240 >set shmsys:shminfo_shmseg = 512 > >The man page for shmget says that for ENOSPC a shared memory identifier is >to be created but the system imposed limit on the maximum number of >allowed identifiers would be exceeded. I have set shmmni to 102400 and had >the same error. Can I actually see how many identifiers I have at one >time, and which processes are creating them? > >Thanks, > >-- >steven > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Throwing die in Apache::Registry
Mark--
While you may be having problems with segfaults because
of expat = yes rule-- i was having similar problems
with XML parser relating to the the die statement.
I do the same thing as far as eval'ing the parsefile
call. Also, I removed the die statement from parser.pm
(v 2.29 line 240 or so) so it would return a useful error
message rather than just die uninformatively.
Maybe this is what you were asking about?
Tom
At 09:19 AM 5/4/01 +0100, Matt Sergeant wrote:
>On Fri, 4 May 2001, Perrin Harkins wrote:
>
>> on 5/4/01 9:28 AM, Mark Maunder at [EMAIL PROTECTED] wrote:
>> > I have an Apache::Registry script that is using XML::Parser. The
parser throws
>> > a
>> > 'die' call if it encounters a parse error (Why?).
>>
>> Because it's an exception and the parser can't continue.
>>
>> > I was handling this by
>> > putting
>> > the code in an eval block, but this no longer works since all Registry
scripts
>> > are already in one huge eval block.
>>
>> It should still work. An eval{} is scoped like any other block. Maybe you
>> have a typo? Post your code and we'll look at it.
>
>More likely is a b0rked $SIG{__DIE__} handler, like fatalsToBrowser. Yick.
>
>--
>
>
>/||** Founder and CTO ** ** http://axkit.com/ **
> //||** AxKit.com Ltd ** ** XML Application Serving **
> // ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
> // \\| // ** mod_perl news and resources: http://take23.org **
> \\//
> //\\
>// \\
>
