Re: svn commit: r559837 - /httpd/httpd/trunk/modules/filters/mod_filter.c
On 07/26/2007 04:48 PM, [EMAIL PROTECTED] wrote:
Author: niq
Date: Thu Jul 26 07:48:48 2007
New Revision: 559837
URL: http://svn.apache.org/viewvc?view=revrev=559837
Log:
Fix integer comparisons in mod_filter
PR: 41835
Modified:
httpd/httpd/trunk/modules/filters/mod_filter.c
Modified: httpd/httpd/trunk/modules/filters/mod_filter.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_filter.c?view=diffrev=559837r1=559836r2=559837
==
@@ -219,9 +225,12 @@
}
break;
case REGEX_MATCH:
-if (ap_regexec(provider-match.regex, str, 0, NULL, 0)
-== AP_REG_NOMATCH) {
-match = 0;
+if (!provider-match.string) {
This is correct (because provider-match is a union and provider-match.string
and
provider-match.regex are the same thing), but confusing. I would prefer
checking provider-match.regex instead.
Regards
Rüdiger
hung apache during shutdown, was: one word syncronize once more
From another thread Re: one word syncronize once more, new thread created as I also don't believe the issues are related. Greg Ames wrote: if you have a hung server, I would do some more diagnosis and not get sidetracked by MRPC. have you looked for unusual messages in the error log, especially messages that mention MaxClients? have you gotten samples of the server-status page with ExtendedStatus on? do you see a pattern with certain URLs that hang and others that do not? are small local static files always served quickly? The hung apache runtime always occur after the leader apache process has been given its signal to terminate. So talking in terms of what web pages it serves makes no sense, since it has already shutdown all further webpage processing. The fatal bug is that the apache leader process does not terminate in good time and remains running. I believe it also hang onto the bound listerning tcp sockets as well, obvious a kill -9 gets rid of it. I'm not sure without any extra information if this list will be able to assist in the matter, maybe there is someway to have apache emit debug logging information to stdout/stderr which I can capture to see where in apache it is hung up and what it is waiting for, maybe a sledgehammer approach of using a SIGALRM and new handler to be put in place as soon as apache begins its shutdown. This new handler will raise a SIGKILL on itself should it go off. Its unlikely I'd have chance to investigate this matter in the short term anyway. I was just using the previous thread as an example to get insight into what actual real life problems may result from lost increment/decrements due to SMP concurrent issues. Darryl
Re: svn commit: r559837 - /httpd/httpd/trunk/modules/filters/mod_filter.c
On 07/26/2007 04:48 PM, [EMAIL PROTECTED] wrote:
Author: niq
Date: Thu Jul 26 07:48:48 2007
New Revision: 559837
URL: http://svn.apache.org/viewvc?view=revrev=559837
Log:
Fix integer comparisons in mod_filter
PR: 41835
Modified:
httpd/httpd/trunk/modules/filters/mod_filter.c
Modified: httpd/httpd/trunk/modules/filters/mod_filter.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/filters/mod_filter.c?view=diffrev=559837r1=559836r2=559837
==
--- httpd/httpd/trunk/modules/filters/mod_filter.c (original)
+++ httpd/httpd/trunk/modules/filters/mod_filter.c Thu Jul 26 07:48:48 2007
@@ -200,18 +200,24 @@
match = 0;
}
}
-else if (!provider-match.string) {
-match = 0;
-}
+/* we can't check for NULL in provider as that kills integer 0
+ * so we have to test each string/regexp case in the switch
+ */
else {
-/* Now we have no nulls, so we can do string and regexp matching
*/
switch (provider-match_type) {
case STRING_MATCH:
-if (strcasecmp(str, provider-match.string)) {
+if (!provider-match.string) {
+match = 0;
+}
+ else if (strcasecmp(str, provider-match.string)) {
match = 0;
}
break;
case STRING_CONTAINS:
+if (!provider-match.string) {
+match = 0;
+break;
+}
Hm. How can provider-match.string == NULL if provider-match_type ~
STRING_MATCH|STRING_CONTAINS?
str1 = apr_pstrdup(r-pool, str);
ap_str_tolower(str1);
if (!strstr(str1, provider-match.string)) {
@@ -219,9 +225,12 @@
}
break;
case REGEX_MATCH:
-if (ap_regexec(provider-match.regex, str, 0, NULL, 0)
-== AP_REG_NOMATCH) {
-match = 0;
+if (!provider-match.string) {
+match = 0;
Same here: How can provider-match.string = provider-match.regex == NULL if
provider-match_type == REGEX_MATCH?
If ap_pregcomp fails in filter_provider we should bail out there IMHO.
Regards
Rüdiger
mod_dbd drivers
I wrote a mod_dbd driver, which opens tcp socket and store it: how can I compile it? can I compile it as .so? And where are mod_dbd drivers located?
Re: svn commit: r559837 - /httpd/httpd/trunk/modules/filters/mod_filter.c
On Thu, 26 Jul 2007 22:08:10 +0200
Ruediger Pluem [EMAIL PROTECTED] wrote:
-else if (!provider-match.string) {
-match = 0;
-}
Lines removed; it's the replacement of those later you're questioning.
+/* we can't check for NULL in provider as that kills
integer 0
+* so we have to test each string/regexp case in the switch
+*/
else {
-/* Now we have no nulls, so we can do string and
regexp matching */
Explanation - I don't recollect it, but I expect I had segfaults at
some point in development, and put the check in to prevent them.
Or maybe it was just to preempt them.
Hm. How can provider-match.string == NULL if provider-match_type ~
STRING_MATCH|STRING_CONTAINS?
Good question.
Same here: How can provider-match.string = provider-match.regex ==
NULL if provider-match_type == REGEX_MATCH? If ap_pregcomp fails in
filter_provider we should bail out there IMHO.
Agreed. I'm happy with the changes you imply in this and your
other post.
On the other hand, removing the check might risk segfaulting in some
future update - perhaps something that gets configuration per-request
from a database and a rewritemap. I've recently had a similar issue
with another module, which started life using match rules defined in
httpd.conf, then grew to derive them from rewritemap+dbm. Worked
fine until it constructed a match-rule from a corrupted database entry.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: one word syncronize once more
the disease: on an SMP system, multiple CPUs could try to update requests_this_child simultaneously, and only one of the updates will take effect. this is a rare timing situation. the SMP issue is not important because the variable will still be updated and continue to do its job. requests_this_child is the variable used to implement MaxRequestsPerChild. this is used to periodically quiesce worker processes which are replaced by new workers and keep the server going if there are slow memory or resource leaks due to bugs. the hope is a worker process that is using more and more memory or file descriptors over time will be shut down before the situation gets serious. it counts the number of connections served by a worker process, contrary to its name. the admin picks a big number out of the air, let's say 1, and sets MaxRequestsPerChild to that value. if he observes that that workers are now being shut down before the leak gets too bad and there isn't a lot of unneccessary process forking/exiting, great! he's done until he has time to address the software bug which is the root cause of the problem. if the workers are still getting too big before quiescing, he lowers MRPC. if there is no more worker growth problem but the CPU is high and he can see workers getting forked very rapidly, he raises MRPC. so if internally the httpd actually processes 10002 connections instead of 1 before quescing some worker process, it isn't important enough to justify slowing down the mainline path. if you have a hung server, I would do some more diagnosis and not get sidetracked by MRPC. have you looked for unusual messages in the error log, especially messages that mention MaxClients? have you gotten samples of the server-status page with ExtendedStatus on? do you see a pattern with certain URLs that hang and others that do not? are small local static files always served quickly? Greg - Original Message From: Darryl Miles [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Friday, July 20, 2007 1:46:53 PM Subject: Re: one word syncronize once more Greg Ames wrote: please see rev. 558039. requests_this_child does not need to be 100% accurate. the cure below is worse than the disease. Greg -requests_this_child--; /* FIXME: should be synchronized - aaron */ +apr_atomic_dec32(requests_this_child); /* much slower than important */ Maybe someone could reconfirm to the list what exactly the disease is ? Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mailp=summer+activities+for+kidscs=bz
