Req #25141 [Opn->Wfx]: Apache: segfault after adding LoadModule with "apachectl restart"

Edit report at http://bugs.php.net/bug.php?id=25141&edit=1 ID: 25141 Updated by: jani@php.net Reported by: jwoolley@php.net Summary: Apache: segfault after adding LoadModule with "apachectl restart" -Status: Open +Status: Wont fix Type: Feature/Change Request -Package: Feature/Change Request +Package: Apache related Operating System: Linux PHP Version: 4.3.2 Block user comment: N Private report: N New Comment: It's always safer to do real restart. Previous Comments: ------------------------------------------------------------------------ [2003-08-19 04:19:51] sniper@php.net Maybe we're doing something wrong then? I don't remember what the exact reason for this 'bug' is..I think it had something to do with the double init by Apache, iirc. Reclassifying as 'non-critical' :) ------------------------------------------------------------------------ [2003-08-19 03:44:07] jwoolley@php.net well, it /seems/ to work with mod_perl, does that count? :) anyway, like i said, it's non-critical. ------------------------------------------------------------------------ [2003-08-19 03:31:38] sniper@php.net Does this work with some other (similar) DSO as PHP is..? This 'bug' actually has existed since Apache 1.3.x. Doing 'make install' and 'apachectl restart' has never really worked. (See para 17. in example 3-4: http://fi.php.net/manual/en/install.apache.php) ------------------------------------------------------------------------ [2003-08-18 23:18:10] jwoolley@php.net Description: ------------ If you install php4 while your server is running, it adds its LoadModule line to the httpd.conf file as you'd expect. If you run "apachectl restart", which executes a non-graceful restart of apache, it succeeds, also as you'd expect. But from then on, all requests cause the child process to segfault. If you stop Apache and start it back up again, then it works as expected. This is obviously a non-critical problem since it's a one-time deal and it's easy to work around. Seemed worth reporting anyway. My guess from the backtrace (where you can see it's trying to lock a pthread mutex from the tsrm) is that because I just restarted rather than stopping and restarting, the tsrm did not have a chance to initialize the pthread mutex that it's trying to lock (hence the null mutexp pointer). Expected result: ---------------- Actual result: -------------- (gdb) bt #0 0x4020691e in pthread_mutex_lock () from /lib/tls/libpthread.so.0 #1 0x4044b047 in tsrm_mutex_lock (mutexp=0x0) at /root/php-4.3.2/TSRM/TSRM.c:520 #2 0x4044adce in ts_resource_ex (id=0, th_id=0x414ecd30) at /root/php-4.3.2/TSRM/TSRM.c:324 #3 0x4048ad88 in php_handler (r=0x81e25a8) at /root/php-4.3.2/sapi/apache2handler/sapi_apache2.c:456 #4 0x080a1f36 in ap_run_handler (r=0x81e25a8) at config.c:195 #5 0x080a244e in ap_invoke_handler (r=0x81e25a8) at config.c:401 #6 0x0808251c in ap_internal_redirect (new_uri=0x81e2598 "/index.html.en", r=0x81d8968) at http_request.c:498 #7 0x0809b8a4 in handle_map_file (r=0x81d8968) at mod_negotiation.c:2983 #8 0x080a1f36 in ap_run_handler (r=0x81d8968) at config.c:195 #9 0x080a244e in ap_invoke_handler (r=0x81d8968) at config.c:401 #10 0x08082067 in ap_process_request (r=0x81d8968) at http_request.c:288 #11 0x0807e2a1 in ap_process_http_connection (c=0x81d49c8) at http_core.c:293 #12 0x080aaf36 in ap_run_process_connection (c=0x81d49c8) at connection.c:85 #13 0x0809f16e in process_socket (p=0x81d48b0, sock=0x81d48e8, my_child_num=1095683460, my_thread_num=0, bucket_alloc=0x8199d00) at worker.c:632 #14 0x0809f7c7 in worker_thread (thd=0x8160e58, dummy=0x414ecd30) at worker.c:947 #15 0x080d1860 in dummy_worker (opaque=0x414ecd30) at thread.c:127 #16 0x40205332 in start_thread () from /lib/tls/libpthread.so.0 ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/bug.php?id=25141&edit=1