php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #71342 Crash in "zend_mm_gc"
Submitted: 2016-01-11 22:35 UTC Modified: 2016-01-27 02:47 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: michael dot hartmann at refx dot com Assigned:
Status: Closed Package: Reproducible crash
PHP Version: 7.0.2 OS: Windows 10
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.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: michael dot hartmann at refx dot com
New email:
PHP Version: OS:

 

 [2016-01-11 22:35 UTC] michael dot hartmann at refx dot com
Description:
------------
Downloaded Windows PHP 7.0.2 x64 (NTS), Wincache 2.0.0.4 and YAML 2.0.0(RC7)

Website works 20% of the time, the other 80% of the time I get:

Faulting application name: php-cgi.exe, version: 7.0.2.0, time stamp: 0x568d8141
Faulting module name: php7.dll, version: 7.0.2.0, time stamp: 0x568d8c40
Exception code: 0xc0000005
Fault offset: 0x000000000039be3e
Faulting process id: 0xe58
Faulting application start time: 0x01d14cbc989dfd84
Faulting application path: E:\PHP7\php-cgi.exe
Faulting module path: E:\PHP7\php7.dll
Report Id: 4d36902c-9377-4fb8-bb37-890a846cf0a4
Faulting package full name: 
Faulting package-relative application ID: 

In the event-viewer

I've used a 3rd party tool to find the fault address, which seems to be

zend_mm_gc + 6E

so it seems it crashes somewhere in the garbage collector.

With 7.0.0 and 7.0.1 I got 100% crashes and the site never worked.

Site is working perfectly fine in all PHP 5.5 and 5.6 versions.

If need be, I would be open for a remote-desktop session from a trusted developer to diagnose the problem further.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-01-12 03:30 UTC] laruence@php.net
-Status: Open +Status: Feedback
 [2016-01-12 03:30 UTC] laruence@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.


 [2016-01-12 03:30 UTC] laruence@php.net
btw, I think it probably relates to YAML, could you try with out it? (like use a pure php implementation of Yaml instead ext)
 [2016-01-14 22:28 UTC] michael dot hartmann at refx dot com
-Status: Feedback +Status: Open
 [2016-01-14 22:28 UTC] michael dot hartmann at refx dot com
I've removed YAML from my php.ini and replaced the necessary functions with the Symfony/YAML parser. It is definitely more stable, but still crashes in 10% of the cases at the exact same location.

Except Wincache, this PHP 7.0.2 installation is vanilla.

Also I can only manage to make it crash if I reload a certain page that does array-value manipulations like this:

// Assign specific display parameters to each price
foreach ($prices as &$prc)
{
	$price = $prc[$_SESSION['GEO']['CURRENCY']];
	$price = $price < 79? ceil($price) : floor($price);

	$prc['PRICE'] = number_format($price, 0, $prdDisp['DECIMAL'], $prdDisp['THOU']);

	// Christmas pricing active?
	if ($this->config['B_CHRISTMAS_PRICES'])
	{
		$prc['OLD_PRICE'] = $prc['PRICE'];

		$price = $prc[$_SESSION['GEO']['CURRENCY'] . '_SPEC'];
		$price = $price < 79? ceil($price) : floor($price);

		$prc['PRICE'] = number_format($price, 0, $prdDisp['DECIMAL'], $prdDisp['THOU']);
	}
}

// Assign various properties to products
foreach ($products as &$prd)
{
	// Slug
	$prd['SLUG'] = trim(preg_replace('/[^a-z0-9-]+/', '-', strtolower($prd['DISPLAY_NAME'])), "-");

	// Price
	$price = $prices[$prd['PRICE_CATEGORY']];
	if ($price['PRICE'] != '0')
	{
		$prd['PRICE'] = $price['PRICE'];
		if ($price['OLD_PRICE'])
		{
			$prd['OLD_PRICE'] = $price['OLD_PRICE'];
		}
		$prd['CURRENCY'] = $prdDisp['SYMBOL'];
	}

	// Age
	$prd['NEW'] = (time() - strtotime($prd['RELEASEDATE'])) < (90 * 24 * 60 * 60);
}

As you can see, I add new array-elements in the foreach loop and I work on references instead of the values.

If I comment this code out, then (even with the yaml.dll) the website get's a LOT more stable.
 [2016-01-17 19:41 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2016-01-17 19:41 UTC] ab@php.net
@michael thanks for the follow up. Were it possible you to extract a small reproduce case? A backtrace or a core dump could be very helpful, too. Please exclude any non core extensions while doing that.

Thanks.
 [2016-01-18 02:53 UTC] michael dot hartmann at refx dot com
-Status: Feedback +Status: Open
 [2016-01-18 02:53 UTC] michael dot hartmann at refx dot com
I wish I could send you a short script that causes it, but it seems everything "simple" just works.

This website uses AltoRouter, Twig and some custom functions (mainly Twig extensions) to render our website.

How do I create the core-dump or a complete backtrace? Keep in mind, I can't run this in the command-line.

My offer that somebody trustworthy does a remote-desktop session and works on my computer directly still stands.
 [2016-01-19 10:00 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2016-01-19 10:00 UTC] ab@php.net
On creating core dumps, an info is here https://bugs.php.net/bugs-generating-backtrace-win32.php or here https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 .

I would see RDP to your machine as not very rational, as you most likely miss all the tools needed to debug and develop the PHP core on Windows. So quite some time would be needed for setups, etc. Please lets see what we have in the dumps (be sure there's no sensitive information in there before posting).

Thanks.
 [2016-01-19 23:28 UTC] michael dot hartmann at refx dot com
-Status: Feedback +Status: Open
 [2016-01-19 23:28 UTC] michael dot hartmann at refx dot com
I've created a full crash-dump. It's 187 MB. Even with simple ZIP compression I get it down to 18 MB. Or is a mini-crash dump enough?

How do you want me to submit that file?
 [2016-01-19 23:34 UTC] michael dot hartmann at refx dot com
I've used the DebugDiag Analysis tool to get the backtrace:

ntdll!NtWaitForMultipleObjects+14    
KERNELBASE!WaitForMultipleObjectsEx+ef    
KERNELBASE!WaitForMultipleObjects+e    
kernel32!WerpReportFaultInternal+4ab    
kernel32!WerpReportFault+52    
KERNELBASE!UnhandledExceptionFilter+277    
ntdll!RtlUserThreadStart$filt$0+3e    
ntdll!_C_specific_handler+96    
ntdll!RtlpExecuteHandlerForException+d    
ntdll!RtlDispatchException+3a9    
ntdll!KiUserExceptionDispatch+3a    
php7!zend_mm_gc+6e [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_alloc.c @ 1891]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_alloc.c @ 1891 
php7!zend_mm_alloc_huge+96 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_alloc.c @ 1761 + 8]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_alloc.c @ 1761 + 8 
php7!_emalloc+32ffcd [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_alloc.c @ 2442 + 12]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_alloc.c @ 2442 + 12 
php7!ZEND_CONCAT_SPEC_TMPVAR_TMPVAR_HANDLER+355021 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 44492]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 44492 
php7!execute_ex+62 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 417 + 5]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 417 + 5 
php7!zend_call_function+355dcd [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_execute_api.c @ 861]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_execute_api.c @ 861 
php7!php_array_user_key_compare+cc [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\ext\standard\array.c @ 1122 + 26]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\ext\standard\array.c @ 1122 + 26 
php7!zend_sort+1d8 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_sort.c @ 351 + f]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_sort.c @ 351 + f 
php7!zend_sort+282 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_sort.c @ 371]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_sort.c @ 371 
php7!zend_hash_sort_ex+85 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_hash.c @ 2256]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_hash.c @ 2256 
php7!php_usort+179 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\ext\standard\array.c @ 1060 + 8]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\ext\standard\array.c @ 1060 + 8 
php7!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+35609e [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 723]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 723 
php7!execute_ex+62 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 417 + 5]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 417 + 5 
php7!zend_execute+16c [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 459]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 459 
php7!zend_execute_scripts+119 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend.c @ 1428]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend.c @ 1428 
php7!php_execute_script+463 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\main\main.c @ 2471 + 1b]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\main\main.c @ 2471 + 1b 
php_cgi!main+117a [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\sapi\cgi\cgi_main.c @ 2492]   c:\php-sdk\php70dev\vc14\x64\php-7.0.2\sapi\cgi\cgi_main.c @ 2492 
php_cgi!__scrt_common_main_seh+124 [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 264 + 22]   f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 264 + 22 
kernel32!BaseThreadInitThunk+22    
ntdll!RtlUserThreadStart+34
 [2016-01-20 10:46 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2016-01-20 10:46 UTC] ab@php.net
Thanks for the backtrace. The analyze shows, that it might be a GC bug while executing some userspace sort functions (like usort, uksort, etc.). Could you please check the places in your code?

Also, please try to rerun PHP with environment variable USE_ZEND_ALLOC=0 set to the PHP environment (fe can be added to the FCGI options in IIS).

Thanks.
 [2016-01-21 21:29 UTC] michael dot hartmann at refx dot com
-Status: Feedback +Status: Open
 [2016-01-21 21:29 UTC] michael dot hartmann at refx dot com
I've added USE_ZEND_ALLOC=0 as the environment variables for the FCGI process in IIS and now it's much less table. It crashes 80% of the time.

Here is the new backtrace of that crash:

ntdll!NtWaitForMultipleObjects+14    
ntdll!RtlReportExceptionEx+480    
ntdll!RtlReportException+c3    
ntdll!RtlReportCriticalFailure$filt$0+33    
ntdll!_C_specific_handler+96    
ntdll!_GSHandlerCheck_SEH+76    
ntdll!RtlpExecuteHandlerForException+d    
ntdll!RtlDispatchException+3a9    
ntdll!RtlRaiseException+324    
ntdll!RtlReportCriticalFailure+8c    
ntdll!RtlpHeapHandleError+12    
ntdll!RtlpLogHeapFailure+96    
ntdll!RtlpReAllocateHeapInternal+8fda5    
ntdll!RtlReAllocateHeap+31    
AcLayers!NS_FaultTolerantHeap::APIHook_RtlReAllocateHeap+31f4    
ucrtbase!realloc+3d    
php7!_erealloc+347d58 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_alloc.c @ 2468 + 8]
php7!ZEND_CONCAT_SPEC_TMPVAR_TMPVAR_HANDLER+97 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 44487]
php7!execute_ex+62 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 417 + 5]
php7!zend_call_function+355dcd [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_execute_api.c @ 861]
php7!php_array_user_key_compare+cc [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\ext\standard\array.c @ 1122 + 26]
php7!zend_sort+11e [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_sort.c @ 334 + d]
php7!zend_hash_sort_ex+85 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_hash.c @ 2256]
php7!php_usort+179 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\ext\standard\array.c @ 1060 + 8]
php7!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+35609e [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 723]
php7!execute_ex+62 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 417 + 5]
php7!zend_execute+16c [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend_vm_execute.h @ 459]
php7!zend_execute_scripts+119 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\zend\zend.c @ 1428]
php7!php_execute_script+463 [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\main\main.c @ 2471 + 1b]
php_cgi!main+117a [c:\php-sdk\php70dev\vc14\x64\php-7.0.2\sapi\cgi\cgi_main.c @ 2492]
php_cgi!__scrt_common_main_seh+124 [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 264 + 22]
ntdll!RtlUserThreadStart+34
 [2016-01-26 00:48 UTC] michael dot hartmann at refx dot com
I will try to create a tiny script that creates a small array, modifies it via references in a foreach loop and then calls usort()/uksort() to provoke the crash.

Please don't close this.
 [2016-01-27 00:46 UTC] michael dot hartmann at refx dot com
Good news. Today a new version of Wincache was released (2.0.5) and after updating the crashes are gone!

So it seems that Wincache was corrupting memory!

Sorry for the wild goose chase.
 [2016-01-27 02:47 UTC] michael dot hartmann at refx dot com
-Status: Open +Status: Closed
 [2016-01-27 02:47 UTC] michael dot hartmann at refx dot com
Issue resolved.
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Sun Mar 29 22:01:26 2020 UTC