Re: Using mod_rewrite in my authorization module. Need advice.
On Thu, Feb 4, 2010 at 10:52 AM, Sorin Manolache sor...@gmail.com wrote:
Try to set an apache request note in the authentication instead of
dynamically changing the configuration of mod_rewrite.c.
Thus, you'll have something like
RewriteRule /url %{ENV:destination}
The configuration would be always the same, just the value of the
destination request note changes dynamically, depending on the
authentication.
H... Interesting. Are you sure that this works?
Can I do something like RewriteRule %{ENV:source} %{ENV:destination} ?
--
Marko Kevac
Sent from Moscow, Mow, Russia
Re: Using mod_rewrite in my authorization module. Need advice.
On Thu, Feb 4, 2010 at 2:05 PM, Sorin Manolache sor...@gmail.com wrote: No, you cannot. The expansion does not work in the pattern (the second argument). But the second argument can be a regular expression. Hopefully you can write regexps for all your cases. Unfortunately I cannot. These should be in DB also, not in httpd.conf. Right now I am rewriting basic rewrite functionality with some mod_rewrite features like [QCA]. I hope this will be enough. -- Marko Kevac Sent from Moscow, Mow, Russia
Re: svn commit: r905454 - in /httpd/httpd/trunk: include/ap_mmn.h include/http_config.h modules/debugging/mod_dumpio.c server/core.c server/log.c server/main.c
On Feb 1, 2010, at 6:27 PM, s...@apache.org wrote:
-else {
-return DumpIOLogLevel requires level keyword: one of
- emerg/alert/crit/error/warn/notice/info/debug;
-}
+err = ap_parse_log_level(str, ptr-loglevel);
+if (err != NULL)
+return err;
}
...
-else {
-return LogLevel requires level keyword: one of
- emerg/alert/crit/error/warn/notice/info/debug;
-}
+err = ap_parse_log_level(arg, cmd-server-loglevel);
+if (err != NULL)
+return err;
}
else {
return LogLevel requires level keyword;
...
+char *err = Loglevel keyword must be one of
emerg/alert/crit/error/warn/
+notice/info/debug;
+int i = 0;
Won't this be confusing that every error would refer to Loglevel, even if the
bad directive is DumpIOLogLevel for example? Why not also pass the directive
name as well?
RE: Is that a race condition bug?
OH my. How hard would it be to fix this?
If you get a patch, could you tell me?
Thanks,
Peter Arseneau.
-Original Message-
From: Tianwei [mailto:tianwei.sh...@gmail.com]
Sent: February 4, 2010 2:21 AM
To: Kostya Serebryany
Cc: dev@httpd.apache.org; Neil Vachharajani
Subject: Re: Is that a race condition bug?
besides, the following warning indicated that developer already have
been aware of the problem and tolerate it:
1. comments in worker.c:
a:
896 requests_this_child--; /* FIXME: should be synchronized - aaron */
b:
632 /* TODO: requests_this_child should be synchronized - aaron */
633 if (requests_this_child = 0) {
634 check_infinite_requests();
635 }
2. reported by tsan:
==5876== WARNING: Possible data race during read of size 4 at 0x6FB768: {{{
==5876==T22 (locks held: {}):
==5876== #0 listener_thread
/home/tianwei/apache/httpd-2.2.14/server/mpm/worker/worker.c:633
==5876== #1 dummy_worker
/home/tianwei/apache/httpd-2.2.14/srclib/apr/threadproc/unix/thread.c:142
==5876== #2 ThreadSanitizerStartThread
/home/tianwei/valgrind/drt/tsan/ts_valgrind_intercepts.c:525
==5876== Concurrent write(s) happened at (OR AFTER) these points:
==5876==T15 (locks held: {}):
==5876== #0 worker_thread
/home/tianwei/apache/httpd-2.2.14/server/mpm/worker/worker.c:895
==5876== #1 dummy_worker
/home/tianwei/apache/httpd-2.2.14/srclib/apr/threadproc/unix/thread.c:142
==5876== #2 ThreadSanitizerStartThread
/home/tianwei/valgrind/drt/tsan/ts_valgrind_intercepts.c:525
==5876== Address 0x6FB768 is 0 bytes inside data symbol requests_this_child
==5876== }}}
Tianwei
On Thu, Feb 4, 2010 at 3:05 PM, Kostya Serebryany k...@google.com wrote:
Looking at the races reported by ThreadSanitizer I can see comments in the
httpd code which look like this:
/* There is an intentional race condition in this design:
* in a multithreaded app, one thread might be reading
* from this cache_element to resolve a timestamp from
* TIME_CACHE_SIZE seconds ago at the same time that
* another thread is copying the exploded form of the
* current time into the same cache_element. ...
So, I afraid there are quite a few intentional races in this code.
It'll be hard to find harmful races among those, unless someone takes time
to annotate the benign races.
--kcc
On Thu, Feb 4, 2010 at 9:42 AM, Tianwei tianwei.sh...@gmail.com wrote:
Hi, httpd developers:
I am using a
tool(http://code.google.com/p/data-race-test/wiki/ThreadSanitizer) to
study the potential race condition bugs in httpd.
I use httpd-2.2.14, and configure with --mpm=worker. For my first
round of testing, it actually reports lots of warning. I am checking
one by one manually. I have analyzed one of the bugs carefully, and
do not know if we should classify it as a benign race or not.
waring description:
1. I enable the USE_ATOMICS_GENERIC where use the hash lock to protect
the apr_atomic_casptr
2. The bug report is:
==5876== WARNING: Possible data race during write of size 8 at 0x429C578:
{{{
==5876== T2 (locks held: {L1}):
==5876== #0 apr_atomic_casptr
/home/tianwei/apache/httpd-2.2.14/srclib/apr/atomic/unix/mutex.c:184
==5876== #1 ap_queue_info_set_idle
/home/tianwei/apache/httpd-2.2.14/server/mpm/worker/fdqueue.c:104
==5876== #2 worker_thread
/home/tianwei/apache/httpd-2.2.14/server/mpm/worker/worker.c:844
==5876== #3 dummy_worker
/home/tianwei/apache/httpd-2.2.14/srclib/apr/threadproc/unix/thread.c:142
==5876== #4 ThreadSanitizerStartThread
/home/tianwei/valgrind/drt/tsan/ts_valgrind_intercepts.c:525
==5876== Concurrent read(s) happened at (OR AFTER) these points:
==5876== T22 (locks held: {}):
==5876== #0 ap_queue_info_wait_for_idler
/home/tianwei/apache/httpd-2.2.14/server/mpm/worker/fdqueue.c:209
==5876== #1 listener_thread
/home/tianwei/apache/httpd-2.2.14/server/mpm/worker/worker.c:642
==5876== #2 dummy_worker
/home/tianwei/apache/httpd-2.2.14/srclib/apr/threadproc/unix/thread.c:142
==5876== #3 ThreadSanitizerStartThread
/home/tianwei/valgrind/drt/tsan/ts_valgrind_intercepts.c:525
3. warning analysis.
listener thread:
apr_status_t ap_queue_info_wait_for_idler(fd_queue_info_t
*queue_info,
apr_pool_t **recycled_pool)
{
/* Block if the count of idle workers is zero */
if (queue_info-idlers == 0) {
rv = apr_thread_mutex_lock(queue_info-idlers_mutex);
while (queue_info-idlers == 0) {
rv = apr_thread_cond_wait(queue_info-wait_for_idler,
queue_info-idlers_mutex);
}
rv = apr_thread_mutex_unlock(queue_info-idlers_mutex);
}
apr_atomic_dec32((queue_info-idlers));
for (;;) {
struct recycled_pool *first_pool = queue_info-recycled_pools;
}
}
worker thread:
Re: Is that a race condition bug?
On Thu, 4 Feb 2010 15:20:54 +0800
Tianwei tianwei.sh...@gmail.com wrote:
besides, the following warning indicated that developer already have
been aware of the problem and tolerate it:
1. comments in worker.c:
a:
896 requests_this_child--; /* FIXME: should be synchronized - aaron
*/
b:
632 /* TODO: requests_this_child should be synchronized - aaron */
633 if (requests_this_child = 0) {
634 check_infinite_requests();
635 }
When evaluating a race condition, you should consider what the worst
possible outcome is if two or more threads collide in a race. If it's
something that matters, then you have a bug that should be fixed.
The precise number of requests served in the lifetime of a worker
process is not exactly critical!
--
Nick Kew
graceful dead
hello list, just a quick question: is there any Apache api to request from within a module a child process (or thread for that matter) to die? I have a module where returning 500 followed by a suicide seems to be the best way to deal with some error conditions. TIA Ralf Mattes
[PATCH] report reached MaxClients more than once
See initial patch attached. (30 seconds between reports is just to
make testing faster.)
Index: server/mpm/worker/worker.c
===
--- server/mpm/worker/worker.c (revision 906552)
+++ server/mpm/worker/worker.c (working copy)
@@ -1550,15 +1550,11 @@
/* no threads are inactive - starting, stopping, etc. */
/* have we reached MaxClients, or just getting close? */
if (0 == idle_thread_count) {
-static int reported = 0;
-if (!reported) {
-/* only report this condition once */
-ap_log_error(APLOG_MARK, APLOG_ERR, 0,
- ap_server_conf,
- server reached MaxClients setting,
consider
- raising the MaxClients setting);
-reported = 1;
-}
+static ap_log_interval_t interval = {0};
+ap_log_error_interval(APLOG_MARK, APLOG_ERR,
apr_time_from_sec(30), 0,
+ interval, 0, ap_server_conf,
+ server reached MaxClients setting,
consider
+ raising the MaxClients setting);
} else {
static int reported = 0;
if (!reported) {
Index: include/http_log.h
===
--- include/http_log.h (revision 906552)
+++ include/http_log.h (working copy)
@@ -169,6 +169,17 @@
const char *fmt, ...)
__attribute__((format(printf,6,7)));
+typedef struct ap_log_interval_t {
+apr_time_t last_report;
+apr_int32_t count;
+} ap_log_interval_t;
+
+AP_DECLARE(void) ap_log_error_interval(const char *file, int line, int level,
+ apr_time_t max_interval, apr_int32_t
max_count,
+ ap_log_interval_t *state,
+ apr_status_t status, const server_rec
*s,
+ const char *fmt, ...);
+
/**
* ap_log_perror() - log messages which are not related to a particular
* request, connection, or virtual server. This uses a printf-like
Index: server/log.c
===
--- server/log.c(revision 906552)
+++ server/log.c(working copy)
@@ -732,6 +732,41 @@
va_end(args);
}
+AP_DECLARE(void) ap_log_error_interval(const char *file, int line, int level,
+ apr_time_t max_interval, apr_int32_t
max_count,
+ ap_log_interval_t *state,
+ apr_status_t status, const server_rec
*s,
+ const char *fmt, ...)
+{
+va_list args;
+char fmt_buf[512];
+apr_time_t now;
+int report = 0;
+
+++state-count;
+
+if (max_interval != 0) {
+now = apr_time_now();
+if ((now - state-last_report) = max_interval) {
+report = 1;
+}
+}
+else if (state-count = max_count) {
+report = 1;
+}
+
+if (report) {
+apr_snprintf(fmt_buf, sizeof fmt_buf, %s (occurred %u times),
+ fmt, state-count);
+va_start(args, fmt);
+log_error_core(file, line, level, status, s, NULL, NULL, NULL,
fmt_buf, args);
+va_end(args);
+
+state-count = 0;
+state-last_report = apr_time_now();
+}
+}
+
AP_DECLARE(void) ap_log_perror(const char *file, int line, int level,
apr_status_t status, apr_pool_t *p,
const char *fmt, ...)
Re: [PATCH] report reached MaxClients more than once
Nice. Maybe change count to messages_skipped but that's just a quibble. I wonder where else this would be handy? Dan
Re: clogging filters and async MPMs
On Thu, Feb 4, 2010 at 6:14 AM, Bryan McQuade bmcqu...@google.com wrote: Hi, I'm reading through the httpd code and I notice that async MPMs will fall back to sync mode in the presence of clogging input filters (at least I think I've got that right). I understand that mod_ssl is a clogging filter. Yep What does it mean to be a clogging filter? How does this break async MPMs? It means the filter buffers in such a way that it might have data inside it, but a poll() on the socket will never return active when it has data ready. It also has to do with filters that change the read/write flow -- we currently don't have a way for an output filter for example to say come back to me when there is data available to READ. This is specifically the mod_ssl problem, because of the SSL protocol, you often need to do a write before you can read, or vice versa. What would it take to make mod_ssl a non-clogging filter? Basically needs two things: 1) Never buffer data inside ssl (feasible I believe) 2) Create a new way for a filter deep inside the chain to indicate we need to wait for a read/write ability on a socket -- this fundamentally is why a Serf bucket model is better than our chained filters. An alternative approach would be changing the flow so filters don't directly call the next filter, putting the core back in control of filter flow, but this is still a non-trivial project. HTH, Paul
Re: [PATCH] report reached MaxClients more than once
On Thu, Feb 4, 2010 at 1:55 PM, Dan Poirier poir...@pobox.com wrote: Nice. Maybe change count to messages_skipped but that's just a quibble. There are probably a lot of quibbles with my 20 second API design :) I wonder first if it is acceptable to the group to do without an init call, and live with the consequences. (no opaque structure/lack of future-proof, more parameters on the logging call) I wonder where else this would be handy? dunno at the moment; at least it would be utilized by the MPMs for this message and the one about getting within MinSpareThreads
Re: Is that a race condition bug?
On Fri, Feb 5, 2010 at 12:14 AM, Nick Kew n...@webthing.com wrote:
On Thu, 4 Feb 2010 15:20:54 +0800
Tianwei tianwei.sh...@gmail.com wrote:
besides, the following warning indicated that developer already have
been aware of the problem and tolerate it:
1. comments in worker.c:
a:
896 requests_this_child--; /* FIXME: should be synchronized -
aaron */
b:
632 /* TODO: requests_this_child should be synchronized - aaron
*/
633 if (requests_this_child = 0) {
634 check_infinite_requests();
635 }
When evaluating a race condition, you should consider what the worst
possible outcome is if two or more threads collide in a race. If it's
something that matters, then you have a bug that should be fixed.
The precise number of requests served in the lifetime of a worker
process is not exactly critical!
Hi, Nick,
You are right. But without application specific knowledge, it's hard for
tool maker to
evaluate if a bug is harmful or not. For this requests_this_child one, I
can also learn that it's not critical.
But for the waring in fdqueue.c, I am not sure because there are already
several race condition fixes in the bug database.
If anyone is very familiar with that part of code, can you help have a look
at my analysis?
Thanks.
Tianwei
--
Nick Kew
--
Sheng, Tianwei
Inst. of High Performance Computing
Dept. of Computer Sci. Tech.
Tsinghua Univ.
