https://bz.apache.org/bugzilla/show_bug.cgi?id=69319

            Bug ID: 69319
           Summary: Apache httpd coredump when user edits file.
           Product: Apache httpd-2
           Version: 2.4.62
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mod_dav_fs
          Assignee: bugs@httpd.apache.org
          Reporter: patr...@ekkel.dev
  Target Milestone: ---

We are experiencing coredumps lately on our httpd server. We have traced the
problem back to webdav.

I don't have any way to reproduce the problem consistently but we observed that
the crash is happening when a user edits a file. The webdav share is mounted
via Macbook finder. The server is being used by around 50 to a 100 users at the
worst. 

When the httpd server crashes we have managed to secure a coredump. I can
submit the whole coredump if that is needed. Below is a gdb backtrace that may
give some insight. 

#0  __pthread_kill_implementation (threadid=<optimized out>,
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007f35f6a956d3 in __pthread_kill_internal (threadid=<optimized out>,
signo=6) at pthread_kill.c:78
#2  0x00007f35f6a3cc4e in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#3  0x00007f35f6a24902 in __GI_abort () at abort.c:79
#4  0x00007f35f6a25767 in __libc_message_impl (fmt=fmt@entry=0x7f35f6bb0b60
"\320{\350\377\003\001") at ../sysdeps/posix/libc_fatal.c:132
#5  0x00007f35f6a34bb7 in __libc_assert_fail
(assertion=assertion@entry=0x7f35f6baceac "\250\333\001",
file=file@entry=0x7f35f6bace97 "", line=line@entry=450, 
    function=function@entry=0x7f35f6bb5730 <__PRETTY_FUNCTION__.1> "\270b") at
__libc_assert_fail.c:31
#6  0x00007f35f6a96b9c in __pthread_mutex_lock_full (mutex=0x7f35f67e5000) at
pthread_mutex_lock.c:450
#7  0x00007f35f6a96c75 in ___pthread_mutex_lock (mutex=<optimized out>) at
pthread_mutex_lock.c:86
#8  0x00007f35f6c180b9 in proc_mutex_pthread_acquire_ex (timeout=-1,
mutex=0x561402a25f18) at locks/unix/proc_mutex.c:780
#9  proc_mutex_pthread_acquire (mutex=0x561402a25f18) at
locks/unix/proc_mutex.c:843
#10 0x00007f35f6c0f9bc in apr_global_mutex_lock (mutex=0x561402a25f00) at
locks/unix/global_mutex.c:106
#11 0x00007f35f65d12e6 in dav_fs_really_open_lockdb
(lockdb=lockdb@entry=0x7f35d8022898) at
/usr/src/debug/httpd-2.4.62-2.fc40.x86_64/modules/dav/fs/lock.c:320
#12 0x00007f35f65d2004 in dav_fs_load_lock_record
(lockdb=lockdb@entry=0x7f35d8022898, key=..., add_method=add_method@entry=23,
direct=direct@entry=0x7f35e4bff980, 
    indirect=indirect@entry=0x7f35e4bff978) at
/usr/src/debug/httpd-2.4.62-2.fc40.x86_64/modules/dav/fs/lock.c:568
#13 0x00007f35f65d57ec in dav_fs_get_locks (lockdb=0x7f35d8022898,
resource=0x7f35d8022768, calltype=0, locks=0x7f35e4bffa10)
    at /usr/src/debug/httpd-2.4.62-2.fc40.x86_64/modules/dav/fs/lock.c:1044
#14 0x00007f35f65ed278 in dav_validate_resource_state (p=0x7f35d801cac8,
resource=resource@entry=0x7f35d8022768, lockdb=0x7f35d8022898,
if_header=if_header@entry=0x0, flags=flags@entry=81, 
    pbuf=pbuf@entry=0x7f35e4bffac0, r=0x7f35d801cb40) at
/usr/src/debug/httpd-2.4.62-2.fc40.x86_64/modules/dav/main/util.c:966
#15 0x00007f35f65edcf2 in dav_validate_request (r=0x7f35d801cb40,
resource=0x7f35d8022768, depth=0, locktoken=<optimized out>,
response=0x7f35e4bffbe0, flags=81, lockdb=<optimized out>)
    at /usr/src/debug/httpd-2.4.62-2.fc40.x86_64/modules/dav/main/util.c:1688
#16 0x00007f35f65e58c7 in dav_method_lock (r=0x7f35d801cb40) at
/usr/src/debug/httpd-2.4.62-2.fc40.x86_64/modules/dav/main/mod_dav.c:3256
#17 0x00005613e27213da in ap_run_handler (r=r@entry=0x7f35d801cb40) at
server/config.c:169
#18 0x00005613e272b286 in ap_invoke_handler (r=0x7f35d801cb40) at
server/config.c:443
#19 0x00005613e2768e93 in ap_process_async_request (r=r@entry=0x7f35d801cb40)
at modules/http/http_request.c:452
#20 0x00005613e27694d3 in ap_process_http_async_connection (c=<optimized out>)
at modules/http/http_core.c:155
#21 ap_process_http_connection (c=<optimized out>) at
modules/http/http_core.c:246
#22 0x00005613e27321ca in ap_run_process_connection (c=c@entry=0x7f354c000f90)
at server/connection.c:42
#23 0x00007f35f654dc46 in process_socket (thd=thd@entry=0x561402ac47d0,
p=<optimized out>, sock=<optimized out>, cs=<optimized out>,
my_child_num=my_child_num@entry=2, 
    my_thread_num=my_thread_num@entry=0) at
/usr/src/debug/httpd-2.4.62-2.fc40.x86_64/server/mpm/event/event.c:1086
#24 0x00007f35f654e676 in worker_thread (thd=0x561402ac47d0, dummy=<optimized
out>) at
/usr/src/debug/httpd-2.4.62-2.fc40.x86_64/server/mpm/event/event.c:2179
#25 0x00007f35f6a936d7 in start_thread (arg=<optimized out>) at
pthread_create.c:447
#26 0x00007f35f6b17414 in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:100


Our httpd configuration looks like this

  ServerName <redacted>
  DocumentRoot "/var/www/share"
  # DirectoryIndex must be "disabled" otherwise WebDav won't work!
  DirectoryIndex disabled
  # Since we can't use DirectoryIndex to prevent: "Cannot serve directory
/var/www/share: No matching DirectoryIndex () found",
  # we will have to rely on rewrite rules to prevent these errors from flooding
the logs.
  RewriteEngine On
  RewriteCond "%{REQUEST_METHOD}" GET
  RewriteRule "^/$" "/index.html" [L]

  SSLEngine on
  SSLProtocol -all +TLSv1.3 +TLSv1.2
  SSLCipherSuite HIGH:!aNULL:!eNULL:!3DES:!DES:!MD5:!SEED:!IDEA
  SSLCertificateFile <redacted>
  SSLCertificateChainFile <redacted>
  SSLCertificateKeyFile <redacted>

  RequestHeader set X-Forwarded-Proto "https"
  RequestHeader set X-Forwarded-Port "443"

  ErrorLog /var/log/httpd/share_error.log
  CustomLog /var/log/httpd/share_access.log common

  <Directory "/var/www/share">
    Dav On

    AuthType Basic
    AuthName "opp-properties"
    AuthUserFile "/etc/httpd/share.passwd"

    <LimitExcept GET HEAD OPTIONS>
        Require valid-user
    </LimitExcept>

    LimitRequestBody 10240
  </Directory>
</VirtualHost>


We are running Fedora 40 with apache 2.4.62, the problems also occured on
2.4.61  

Another thing that is interesting to mention is that the server never recovers
from the crash. When it tries to recover it crashes again and stays in a
restart/coredump/restart loop. 

If any additional information is needed and or found. I be happy to update the
bugreport.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

Reply via email to