https://issues.apache.org/bugzilla/show_bug.cgi?id=45605
Denis Ustimenko <[EMAIL PROTECTED]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
--- Comment #4 from Denis Ustimenko <[EMAIL PROTECTED]> 2008-10-07 07:08:42
PST ---
The same was reproduced several times under a heavy load with the 1 process / 2
thread configuration. Due to the data corruption by the worker_queue overflow
the core is dumped. Inspecting the core files, the underflow of
worker_queue_info.idlers is found.
Finally, that looks like the race between the condition signal and the atomic
update of the idlers variable.
The following scheduling scenario leads to the idlers underflow:
0. one listener + worker thread
1. listener got a connection, decreases idlers to 0, then context switch
2. worker does his job set the idlers from 0 to 1,
then context switch before the condition signal
3. listener got a connection, sees that idlers is 1,
so decreases is to 0, gets another connection,
waits on the condition variable
4. worker remembering that the idlers was 0,
does the cond_signal, then context switch
5. listener wakes up and set idlers to -1
The 2.2.9 patch is the following. The similar patch for 2.2.3 is currently
under the test.
--- server/mpm/worker/fdqueue.c.fdqueue-overflow 2006-07-12
07:38:44.000000000 +0400
+++ server/mpm/worker/fdqueue.c 2008-10-07 13:53:28.000000000 +0400
@@ -166,7 +166,7 @@
* now nonzero, it's safe for this function to
* return immediately.
*/
- if (queue_info->idlers == 0) {
+ while (queue_info->idlers == 0) {
rv = apr_thread_cond_wait(queue_info->wait_for_idler,
queue_info->idlers_mutex);
if (rv != APR_SUCCESS) {
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
