|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #25141 Apache: segfault after adding LoadModule with "apachectl restart"
Submitted: 2003-08-18 23:18 UTC Modified: 2011-01-01 21:00 UTC
From: Assigned:
Status: Wont fix Package: Apache related
PHP Version: 4.3.2 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
New email:
PHP Version: OS:


 [2003-08-18 23:18 UTC]
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/ 
#1  0x4044b047 in tsrm_mutex_lock (mutexp=0x0) at 
#2  0x4044adce in ts_resource_ex (id=0, th_id=0x414ecd30) at 
#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 
#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 
#11 0x0807e2a1 in ap_process_http_connection (c=0x81d49c8) at 
#12 0x080aaf36 in ap_run_process_connection (c=0x81d49c8) at 
#13 0x0809f16e in process_socket (p=0x81d48b0, sock=0x81d48e8, 
    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 
#16 0x40205332 in start_thread () from /lib/tls/ 


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-08-19 03:31 UTC]
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:

 [2003-08-19 03:44 UTC]
well, it /seems/ to work with mod_perl, does that count?  :) 
anyway, like i said, it's non-critical.
 [2003-08-19 04:19 UTC]
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' :)

 [2011-01-01 21:00 UTC]
-Status: Open +Status: Wont fix -Package: Feature/Change Request +Package: Apache related
 [2011-01-01 21:00 UTC]
It's always safer to do real restart.
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Tue Apr 07 17:01:26 2020 UTC