php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #68205 Intermittent crash, exception 0xc0000005 in php5ts.dll
Submitted: 2014-10-10 09:09 UTC Modified: 2014-12-23 19:12 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: leon at howtomoodle dot com Assigned:
Status: No Feedback Package: Apache2 related
PHP Version: 5.5.17 OS: Windows Server 2008 R2
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: leon at howtomoodle dot com
New email:
PHP Version: OS:

 

 [2014-10-10 09:09 UTC] leon at howtomoodle dot com
Description:
------------
I'm seeing an intermittent crash on a production server hosting a Moodle site. Windows event log details:

Faulting application name: httpd.exe, version: 2.4.10.0, time stamp: 0x53c79afa
Faulting module name: php5ts.dll, version: 5.5.17.0, time stamp: 0x5418c5a5
Exception code: 0xc0000005
Fault offset: 0x0004b985
Faulting process id: 0xf34
Faulting application start time: 0x01cfdd698c1dc0b3
Faulting application path: E:\Server\Apache24\bin\httpd.exe
Faulting module path: E:\Server\PHP\php5ts.dll

Test script:
---------------
N/A - I've been unable to identify the code triggering this.

Actual result:
--------------
In httpd__PID__3732__Date__10_03_2014__Time_09_30_49AM__739__Second_Chance_Exception_C0000005.dmp the assembly instruction at php5ts!_zend_hash_quick_add_or_update+34 in E:\Server\PHP\php5ts.dll from The PHP Group has caused an access violation exception (0xC0000005) when trying to read from memory location 0x00000000 on thread 65

Thread 65 - System ID 1160

Entry point   libhttpd!ap_regkey_value_set+1bf0 
Create time   03/10/2014 09:14:51 
Time spent in user mode   0 Days 00:00:02.215 
Time spent in kernel mode   0 Days 00:00:00.577 

Function  Source
php5ts!_zend_hash_quick_add_or_update+34 [c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\zend\zend_hash.c @ 295 + a]   c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\zend\zend_hash.c @ 295 + a 
php_opcache!persistent_compile_file+5ad [c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\ext\opcache\zendaccelerator.c @ 1674 + 28]   c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\ext\opcache\zendaccelerator.c @ 1674 + 28 
php5ts!zend_execute_scripts+af [c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\zend\zend.c @ 1322 + c]   c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\zend\zend.c @ 1322 + c 
php5apache2_4!php_handler+2e7f [c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\sapi\apache2handler\sapi_apache2.c @ 669 + e]   c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\sapi\apache2handler\sapi_apache2.c @ 669 + e 
php5apache2_4!php_handler+1c1 [c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\sapi\apache2handler\sapi_apache2.c @ 611 + 3a]   c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\sapi\apache2handler\sapi_apache2.c @ 611 + 3a 
kernel32!BaseThreadInitThunk+e    
ntdll!__RtlUserThreadStart+70    
ntdll!_RtlUserThreadStart+1b

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-10-10 09:25 UTC] leon at howtomoodle dot com
The PHP files were downloaded from http://windows.php.net/downloads/releases/php-5.5.17-Win32-VC11-x86.zip, the Apache files from http://www.apachelounge.com/download/VC11/binaries/httpd-2.4.10-win32-VC11.zip. The backtrace above is with OPcache enabled which may obfuscate the problem(?).  Most of the backtraces contain the message "This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required." and I've been unable to capture a backtrace that doesn't contain this warning with OPcache turned off. Here's an example, with OPcache turned off in case it helps:

Entry point   libhttpd!ap_regkey_value_set+1bf0 
Create time   07/10/2014 11:30:52 
Time spent in user mode   0 Days 00:00:01.450 
Time spent in kernel mode   0 Days 00:00:00.109 

This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.

Function  Source
php5ts!zend_hash_find+f0 [c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\zend\zend_hash.c @ 924 + 5]   c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\zend\zend_hash.c @ 924 + 5 
php5ts!zend_set_compiled_filename+3b [c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\zend\zend_compile.c @ 254 + 29]   c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\zend\zend_compile.c @ 254 + 29 
php5ts!open_file_for_scanning+10b [c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\zend\zend_language_scanner.l @ 539]   c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\zend\zend_language_scanner.l @ 539 
php5ts!compile_file+6e [c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\zend\zend_language_scanner.l @ 574 + 9]   c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\zend\zend_language_scanner.l @ 574 + 9 
php5ts!phar_compile_file+204 [c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\ext\phar\phar.c @ 3383 + 19]   c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\ext\phar\phar.c @ 3383 + 19 
0x05b538c8    
php5ts!phar_compile_file+1eb [c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\ext\phar\phar.c @ 3383]   c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\ext\phar\phar.c @ 3383 
libapr_1!apr_pstrcat+86    
msvcr110!__crtFlsGetValue+15    
msvcr110!_getptd_noexit+6a    
0x058fe168    
php5apache2_4!php_handler+1c1 [c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\sapi\apache2handler\sapi_apache2.c @ 611 + 3a]   c:\php-sdk\php55\vc11\x86\php-5.5.17-ts\sapi\apache2handler\sapi_apache2.c @ 611 + 3a 
kernel32!BaseThreadInitThunk+e    
ntdll!__RtlUserThreadStart+70    
ntdll!_RtlUserThreadStart+1b
 [2014-10-13 09:11 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2014-10-13 09:11 UTC] ab@php.net
Thanks for reporting. Yeah, a crash with opcache enabled might be well just a consequence of the original issue. So lets concentrate on naling the issue without opcache first.

Maybe it would be possible to at least extract an URL on which the crash was happening (probably some item with 500 status in the logs)? Or maybe you could try to reproduce on some dev system, then there were some more room for debugging.

Unfortunately disabling phar won't work as it's compiled statically. Btw are there some phar files used in the app, by chance? It could be, that phar clashes with some extension which needs to be loaded before phar, but it's hard to guess without being able to properly debug

Thanks
 [2014-12-23 19:12 UTC] ab@php.net
-Status: Feedback +Status: No Feedback
 [2014-12-23 19:12 UTC] ab@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Dec 27 01:01:28 2024 UTC