apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 57877] New: Adding a buffer using apr_file_buffer_set() leaves an unbuffered file w/o the required mutex
Date Thu, 30 Apr 2015 14:20:05 GMT

            Bug ID: 57877
           Summary: Adding a buffer using apr_file_buffer_set() leaves an
                    unbuffered file w/o the required mutex
           Product: APR
           Version: 1.5.1
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: APR
          Assignee: bugs@apr.apache.org
          Reporter: ernstthal@icloud.com

Created attachment 32705
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=32705&action=edit
Patch to apr_file_open() & apr_os_file_put() to always associate a mutex

The default case is to open a file unbuffered, and such a file won't get a
mutex as it is only required for protecting access to the buffer (aside from
the APR_FOPEN_APPEND option). apr_file_buffer_set() can be used to assign a
buffer afterwards, but no mutex will be allocated.

Moreover the implementation for Windows in apr-1.5.1/file_io/win32/buffer.c
tries to apr_thread_mutex_lock() with a NULL mutex in this case, causing
logresolve.exe from httpd-2.4.x to always fail.

The implementation for UNIX of apr_file_buffer_set() (in
apr-1.5.1/file_io/unix/buffer.c) differs by applying the file_lock() & -unlock
macros from apr-1.5.1/include/arch/unix/apr_arch_file_io.h which in turn will
only call apr_thread_mutex_lock() & -unlock if the mutex exists.

My first idea was to create the mutex on demand as shown in the following
--- apr/file_io/win32/buffer-old.c    2006-08-03 12:55:31.000000000 +0200
+++ apr/file_io/win32/buffer.c    2015-04-28 17:03:02.919790000 +0200
@@ -23,6 +23,14 @@
     apr_status_t rv;

+    if (!file->mutex) {
+        rv = apr_thread_mutex_create(&file->mutex,
+                                     APR_THREAD_MUTEX_DEFAULT, file->pool);
+        if (rv) {
+            return rv;
+        }
+    }

     if(file->buffered) {
but creating a new mutex for an opened file would have to be protected by a
mutex on its own. The only save option is to create the mutex right on every
open, even if it won't be used later on (at least #if APR_HAS_THREADS).

Attached is a patch for apr-1.5.1/file_io/win32/open.c with small changes
inside apr_file_open() & apr_os_file_put() commenting out the if statements.

You are receiving this mail because:
You are the assignee for the bug.

To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org

View raw message