On Dec 12, 2006, at 5:43 PM, Grant wrote:
>> > Hello, I've been plagued by apache2 segfaults ever since I started>> > using Interchange::Link years ago. The latest Link.pm has ALERT >> > messages accompanying the segfaults in error_log: >> > >> > ALERT: bad pipe signal received for /page.html >> > [Sat Dec 09 10:27:55 2006] [notice] child pid 21337 exit signal >> > Segmentation fault (11) >> > >> > Does anyone have any advice on solving this? I'm using >> apache-2.0.58 >> > and mod_perl-2.0.2 in Gentoo Linux. >> >> Also, here is the portion of Link.pm that the ALERT seems to come >> from: >>>> # Return this message to the browser when the server is not running.>> # Log an error log entry if set to notify >> >> sub die_page { >> >> my $r = shift; >> my $msg; >>>> warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME} \n";>> >> $r->content_type ("text/html"); >> $r->print (<<EOF); >> <HTML><HEAD><TITLE>Interrupted</TITLE></HEAD> >> <BODY BGCOLOR="#FFFFFF"> >> <H3>Someone pressed stop...</H3> >> <P> >> We have aborted this request because someone terminated it. >> Please try again soon. >> </BODY></HTML> >> EOF >> >> } >> >> Please let me know if you have any ideas. > > The segfaults are eliminated by commenting out the $r stuff in the > die_page sub. I still get the ALERTs though. Does anyone have any> advice on figuring out why I'm having the bad pipe problem? Is there> an easy way to add extra debugging info to the sub? > > Also, restarting IC with PERL_SIGNALS=unsafe increases the ALERTs > 50 fold. I've been seeing this too, on my Apache 2 and latest Link.pm. I also had to use PERL_SIGNALS=unsafe and so I get quite a lot of these. The visible effect on the browser is that the page or image (which Link.pm apparently still has some part in delivering) does not load. I get them myself when browsing and testing my websites, and I have never stopped loading a page or had any other problems on non-IC sites I host. I was told the problem stems from either the browser and a stop button or some other network fault. I may go back to Apache 1.3 to get around this.I've been working on this all day and I think I may have a solution. Incidentally, I want to mention that if I add $! to the Link.pm warn line, I can see that there are two different types of ALERTs in error_log: Broken pipe Inappropriate ioctl for device Also incidentally, hitting F5 repeatedly always prints a few ALERTS in error_log, but the number of ALERTs printed seems to be about 10 times more for an http page than for the same page accessed via https. I checked and tested the settings in my *:80 and *:443 vhosts trying to narrow that down, but I didn't come up with anything. Now, as I mentioned a few posts back, commenting out the html delivery stuff in the die_page sub of Link.pm eliminates the segfaults in error_log but not the ALERTs. Today I enabled the prefork mpm in apache2 and tinkered with the Server/Child settings in interchange.cfg and httpd.conf and that did seem to reduce the ALERTs somewhat. After all of this, I've been browsing around my site and I haven't seen a single image or page fail to load like it used to. The thing is, ALERTs still show up in error_log even for requests I'm sure I created myself AND WERE SERVED SUCCESSFULLY. I hypothesize that the failed requests were because a $SIG{PIPE} was generated for whatever reason (although not because the user clicked the stop button), the html was delivered, it caused a segfault, and the request failed. I should mention though, that if the failing request syndrome is fixed, it could also be from the apache2, httpd.conf, or interchange.cfg modifications mentioned above. I doubt it though. Incidentally, I'd like to mention that the ALERTs can be generated pretty reliably by hitting the browser's stop button in the middle of a request, clicking on the same link again or a different link in the middle of a request (my Mom probably still double clicks links), or just refreshing the page in the middle of a request. If the failed requests do stop at this point, I think the die_page section of Link.pm is doing more harm than good. Is there anything wrong with not handling $SIG{PIPE} at all?
Grant,Shouldn't the $SIG{PIPE} be ignored at least? I don't know if there are implications for not handling it. Search perlipc manpage for PIPE.
-- Josh Lavin Kingdom Design http://www.kingdomdesign.com/ _______________________________________________ interchange-users mailing list suppressed http://www.icdevgroup.org/mailman/listinfo/interchange-users
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.