Re: Segfaults when using XML::Parser
Thanks. I found that I was using a custom apache build without that enabled, but it is fixed now with a newer apache RPM for redhat. Thanks again. On Mon, 14 Oct 2002, Bruno Connelly wrote: > David> If you have some of the processes segfault when using > David> XML::Parser you should use > > David> --disable-rule=EXPAT > > David> during the Apache configuration step. > David> > David> Starting from mod_perl version 1.23 this option is > David> disabled by default. > > David> It is unclear to me where this disable-rule is specified. > > In the configure line for Apache, like so: > > ./configure --disable-rule=EXPAT \ > --activate-module=src/modules/perl/libperl.a > > David> I would assume in apache, but then it makes a statement that > David> the option has been disabled by default for mod_perl 1.23+. > David> That seems to imply the option is in mod_perl? > > That's assuming you have the mod_perl distribution build Apache for > you, not if you're doing it the other way around. > > David> Can someone please give me specific information about how I > David> would go about using this disable-rule to fix the > David> afformentioned problem. > > The above should help. > > David> Can someone also give me some information on why this is > David> needed to fix the problem...what is the root cause of this > David> problem? I have only ran into this problem on my fully > David> updated RedHat 7.3 box (apache 1.3.23 & mod_perl 1.26), not > David> my RH 6.2 (apache 1.3.12 & mod_perl 1.24) boxes. Please > David> advise. > > XML::Parser doesn't hide it's symbols properly and hence they collide > with the expat-lite that's in Apache by default. I can't believe this > hasn't been fixed by now. > > Nonetheless, this subject has been covered over and over on the list. > If you look in the archives you'll most certainly find more details. > > b. > -- > /* Bruno Connelly, <[EMAIL PROTECTED]> */ > > > - David Castro Software Architect Collaborative Technologies Information & Media Technology Azusa Pacific University "My little children, let us not love in word or in tongue, but in deed and in truth." -- 1 Jn 3:18 (NKJ)
Re: Segfaults when using XML::Parser
David>If you have some of the processes segfault when using David>XML::Parser you should use David>--disable-rule=EXPAT David>during the Apache configuration step. David> David>Starting from mod_perl version 1.23 this option is David>disabled by default. David> It is unclear to me where this disable-rule is specified. In the configure line for Apache, like so: ./configure --disable-rule=EXPAT \ --activate-module=src/modules/perl/libperl.a David> I would assume in apache, but then it makes a statement that David> the option has been disabled by default for mod_perl 1.23+. David> That seems to imply the option is in mod_perl? That's assuming you have the mod_perl distribution build Apache for you, not if you're doing it the other way around. David> Can someone please give me specific information about how I David> would go about using this disable-rule to fix the David> afformentioned problem. The above should help. David> Can someone also give me some information on why this is David> needed to fix the problem...what is the root cause of this David> problem? I have only ran into this problem on my fully David> updated RedHat 7.3 box (apache 1.3.23 & mod_perl 1.26), not David> my RH 6.2 (apache 1.3.12 & mod_perl 1.24) boxes. Please David> advise. XML::Parser doesn't hide it's symbols properly and hence they collide with the expat-lite that's in Apache by default. I can't believe this hasn't been fixed by now. Nonetheless, this subject has been covered over and over on the list. If you look in the archives you'll most certainly find more details. b. -- /* Bruno Connelly, <[EMAIL PROTECTED]> */
Re: Segfaults when using XML::Parser
I have found this section under the "Warnings and Errors Troubleshooting" on the web site. It states: If you have some of the processes segfault when using XML::Parser you should use --disable-rule=EXPAT during the Apache configuration step. Starting from mod_perl version 1.23 this option is disabled by default. It is unclear to me where this disable-rule is specified. I would assume in apache, but then it makes a statement that the option has been disabled by default for mod_perl 1.23+. That seems to imply the option is in mod_perl? Can someone please give me specific information about how I would go about using this disable-rule to fix the afformentioned problem. Can someone also give me some information on why this is needed to fix the problem...what is the root cause of this problem? I have only ran into this problem on my fully updated RedHat 7.3 box (apache 1.3.23 & mod_perl 1.26), not my RH 6.2 (apache 1.3.12 & mod_perl 1.24) boxes. Please advise. - David Castro Software Architect Collaborative Technologies Information & Media Technology Azusa Pacific University "My little children, let us not love in word or in tongue, but in deed and in truth." -- 1 Jn 3:18 (NKJ)
RE: Segfaults
Thanks Kyle! First it'll stay in the archive for other to use if needed. Second, I'll through it into the todo list in the docs project, core developer's guide, and someone will hopefully clean this thing up when the time comes. BTW, I suppose that we write a similar scenario for strace, ktrace and other tracing utils. will place on todo. [the steps to get a core file are snipped] _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: Segfaults
> what happens to the newly spawned processes? The -f tells truss to follow forks. For completeness... The -l (that's an el) includes the thread-id and the pid (the pid is what we want). The -t specifies the syscalls to trace, and the !all turns them all off. The -s specifies signals to trace and the !SIGALRM turns off the numerous alarms Apache creates. The -S specifies signals that stop the process. Obviously, -p is used to specify the pid. > what happens if the process segfaults immediately after it starts. You > don't have enough time to get its PID. I suppose you could be less lazy than I and edit apachectl to call truss instead of using the -p option. :-) truss -f -l -t \!all -s \!SIGALRM -S SIGSEGV /usr/local/bin/httpd -f httpd.conf 2>&1 & > Since I don't have an access to a Solaris system, is it possible for you > to take the example code I've supplied below and apply these steps to it? > So we can get a fully working example? Thanks a lot! (for example I'm not > familiar with gcore... is it Solaris specific thing?) gcore(1) will get a core image of a running process. Therefore, you can put the core where you want it and have permission to write it. I assume it's a Solaris goodie. I don't have the pointer to the Bad::Segv module, but here's an example run. To get the messages from truss, you need to keep your tty open. Otherwise, redirect stdout/stderr somewhere else. $ apachetl start $ for pid in `ps -ef -o pid,comm | fgrep httpd | cut -d'/' -f1`; do truss -f -l -t \!all -s \!SIGALRM -S SIGSEGV -p $pid 2>&1 & done [1] 23353 [2] 23354 <-- I'm only running one child for this example $ kill -SEGV 662 <-- faking Bad::Segv (662 is the child pid) 662/1: Received signal #11, SIGSEGV, in accept() [caught] 662/1:siginfo: SIGSEGV pid=23306 uid=0 $ gcore 662 gcore: core.662 dumped $ kill -9 662 <-- clean up the stopped process (at this point, Apache forked a new child and truss is hooked on that one too) $ pkill truss <-- clean up the other truss processes that are still running $ gdb /usr/local/bin/httpd (gdb) core-file core.662 ... #0 0xdfae4d2c in _so_accept () from /usr/lib/libc.so.1 (gdb) Obviously, this isn't great to be doing on a production system since truss stops the process after it dumps core and prevents Apache from reaping it. So, you could use up a bunch of scoreboard slots and perhaps force httpd to hit MaxClients if you segfault a lot. -- Kyle Oppenheim Tellme Networks, Inc. http://www.tellme.com -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Monday, August 06, 2001 8:33 PM To: Kyle Oppenheim Cc: mod_perl list Subject: RE: Segfaults [CC'ing back to the list for archival and possibly interesting followup discussion] On Mon, 6 Aug 2001, Kyle Oppenheim wrote: > Here's another method to generate a core on Solaris that you may want to add > to the guide. (I hope I'm not repeating something already in the guide!) > > 1. Use truss(1) as root to stop a process on a segfault: > > truss -f -l -t \!all -s \!SIGALRM -S SIGSEGV -p > > or, to monitor all httpd processes (from bash): > > for pid in `ps -eaf -o pid,comm | fgrep httpd | cut -d'/' -f1`; > do truss -f -l -t \!all -s \!SIGALRM -S SIGSEGV -p $pid 2>&1 & > done what happens to the newly spawned processes? what happens if the process segfaults immediately after it starts. You don't have enough time to get its PID. > 2. Watch the server error_log for reaped processes > > 3. Use gcore to get a core of stopped process or attach gdb. > > 4. kill -9 the stopped process. Since I don't have an access to a Solaris system, is it possible for you to take the example code I've supplied below and apply these steps to it? So we can get a fully working example? Thanks a lot! (for example I'm not familiar with gcore... is it Solaris specific thing?)
RE: Segfaults
[CC'ing back to the list for archival and possibly interesting followup discussion] On Mon, 6 Aug 2001, Kyle Oppenheim wrote: > Here's another method to generate a core on Solaris that you may want to add > to the guide. (I hope I'm not repeating something already in the guide!) > > 1. Use truss(1) as root to stop a process on a segfault: > > truss -f -l -t \!all -s \!SIGALRM -S SIGSEGV -p > > or, to monitor all httpd processes (from bash): > > for pid in `ps -eaf -o pid,comm | fgrep httpd | cut -d'/' -f1`; > do truss -f -l -t \!all -s \!SIGALRM -S SIGSEGV -p $pid 2>&1 & > done what happens to the newly spawned processes? what happens if the process segfaults immediately after it starts. You don't have enough time to get its PID. > 2. Watch the server error_log for reaped processes > > 3. Use gcore to get a core of stopped process or attach gdb. > > 4. kill -9 the stopped process. Since I don't have an access to a Solaris system, is it possible for you to take the example code I've supplied below and apply these steps to it? So we can get a fully working example? Thanks a lot! (for example I'm not familiar with gcore... is it Solaris specific thing?) > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Stas Bekman > Sent: Friday, August 03, 2001 7:53 PM > To: Andrei A. Voropaev > Cc: [EMAIL PROTECTED] > Subject: Re: Segfaults > > > On Fri, 3 Aug 2001, Andrei A. Voropaev wrote: > > > Hi! > > > > The problem with Apache/mod_perl children segfaulting is pretty old. > Unfortunately this > > does not leave any core dump that would help in tracing the problem. All > it > > leaves is messages in error log > > > > [Fri Aug 3 05:39:28 2001] [notice] child pid 446 exit signal Segmentation > > fault (11) > > > > And quite a lot of them. The more we use mod_perl the more messages like > this. > > A year ago we had only authentication in mod_perl and these message showed > up > > 5-6 times a day. Now we run Mason (v 0.89) and the messages show up 2-3 > times > > a minute. (This has nothing to do with increased usage) The problem has > > survived 3 upgrades (we started with mod_perl/1.21) > > > > So my question is - is there any way to force coredumps? :) > > This is an excerpt from the upcoming book (which we will finish at some > point :) > > =head2 Getting the core File Dumped > > Now let's get the I file dumped from within the mod_perl > server. Sometimes the program aborts abnormally via the SIGSEGV signal > (I), but no I file is dumped. And without > the I file it's hard to find the cause of the problem, unless > you run the program inside C or another debugger in first > place. In order to get the I file, the application has to: > > =over > > =item * > > have the effective UID the same as real UID (the same goes for > GID). Which is the case of mod_perl unless you modify these settings > in the program. > > =item * > > be running from a directory which at the moment of the > I is writable by the process. Notice that the > program might change its current directory during its run, so it's > possible that the I file will need to be dumped in a different > directory from the one the program was started from. For example when > mod_perl runs an C script it changes its directory > to the one in which the script source is located. > > =item * > > be started from a shell process with sufficient resource allocations > for the I file to be dumped. You can override the default > setting from within a shell script if the process is not started > manually. In addition you can use C to manipulate the > setting from within the code as well. > > You can use C for C and C for C to check and > adjust the resource allocation. For example inside C, you may > set the core file size to unlimited: > > panic% ulimit -c unlimited > > For example you can set an upper limit on the I file size to 8MB > with: > > panic% ulimit -c 8388608 > > So if the core file is bigger than 8MB it will be not created. > > =item * > > Of course you have to make sure that you have enough disk space to > create a big core file (mod_perl I files tend to be of a few > MB in size). > > =back > > Note that when you are running the program under a debugger like > C, which traps the C signal, the I file will not > be dumped. Instead it allows you to examine the program stack and > other things without having the I file. > > So let's write a simple script that uses C: > > core_dump.pl > > use strict; >
Re: Segfaults with Frontier::RPC2 (possibly XML::Parser)
[for the archive] I wrote: > I have intermittent segmentation faults with Apache 1.3.14, mod_perl > version 1.24. I think I tracked the problem down to the Frontier::RPC2 > module, which uses XML::Parser. The problem has been fixed - the culprit was the version of XML::Parser/ expat I was using. I'm running fine now with version 2.29, and have not had a single segfault since I installed it. Many thanks to Aaron E. Ross and Luc Willems, whose help was invaluable. cheers, stefan
Re: Segfaults with RH6.1, mod_perl, perl 5.6.0, and apache 1.3.12
On Mon, 10 Apr 2000, Benjamin Reed wrote: > I'm getting segfaults with a RedHat 6.1 system. I've tried mod_perl 1.22, > as well as a CVS snapshot from today, and I pretty much get the same thing > either way. I would appreciate it if anyone could help me out on this, it's > driving me nuts. does 'make test' pass for you? if so, we'll need more details on what your server is doing, e.g. using XML::Parser?
Re: SegFaults caused by Apache::Cookie during ChildExit
On Wed, 22 Dec 1999, Clinton Gormley wrote: > I am using a home-baked session manager on my web site. I clean up > expired sessions by called a child exit handlder and this all worked > rather well. > > However, we have recompiled Perl, Apache, mod_perl and Perl modules with > pgcc and a different configuration (removed all modules we didn't need), > and now I get a SegFault when Apache::Cookie->new is called during a > ChildExit. > > I use Apache::Cookie in Authorization and PerlHandler phases without a > problem. > > Not sure whether this problem is caused by the compiler or the different > configuration at compile. > > Any ideas of starting points? Apache::Cookie needs a request_rec, there is no request_rec during ChildExit. this dependency could probably be loosened, but it won't work with the current version of libapreq.
