Bug #75074 [Fbk->Asn]: php-process crash when is_file() is used with strings longer 260 chars

From: Date: Thu, 28 Sep 2017 12:45:30 +0000
Subject: Bug #75074 [Fbk->Asn]: php-process crash when is_file() is used with strings longer 260 chars
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-211415@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=75074&edit=1 ID: 75074 User updated by: trpro at gmx dot de Reported by: trpro at gmx dot de Summary: php-process crash when is_file() is used with strings longer 260 chars -Status: Feedback +Status: Assigned Type: Bug Package: Filesystem function related Operating System: Windows 7 -PHP Version: 7.1.8 +PHP Version: 7.1.8, 7.1.9, 7.1.10 Assigned To: ab Block user comment: N Private report: N New Comment: I used the debug symbols, as described in https://bugs.php.net/bugs-generating-backtrace-win32.php. The crash only occurs with the "PHP 7.1.x x86 NTS"-Binarys from http://windows.php.net/download#php-7.1. If i used a self compiled PHP 7.1.8, the app will not crash (but i used a differend configuration). I still can reproduce this behaivor on several machines (All of them with Win7 64bit, latest updates, Intel i5). Previous Comments: ------------------------------------------------------------------------ [2017-09-28 11:57:45] ab@php.net @steve dot eidemiller at gmail dot com i've tried x86 and x64 on win7 and server 2012r2, but without luck. If you could extract a piece of code to reproduce it, it would be great. Maybe also you could play with it on other machines, with other locale, etc. which could help to figure out the difference. Also, 7.1.10 is getting released now, so worth to try as well. Thanks. ------------------------------------------------------------------------ [2017-09-25 13:07:58] steve dot eidemiller at gmail dot com Appcrash with is_file() string parameter > 260 characters. This happened to me as well, and it seems repeatable at the moment. Adding my BT here in case it helps. Also, my environment is different: Windows Server 2012 R2 Build 9600 x64 with PHP 7.1.8 CLI NTS MSVC14 x64. The test script above did not trigger the exception for me. I found the issue with a batch that takes several minutes to run, and triggers the exception every time at the same place. However, capturing the offending 260+ character string from that process won't trigger the exception outside of that long process. And, of course, truncating the same offending string to 260 characters inside the process fixes the issue. I'll continue to troubleshoot, but for me it seems related to other state information within the process. My BT is as follows: Thread 0 - System ID 4668 Entry point php!php_cli_get_shell_callbacks+5f0 Create time 9/22/2017 2:58:43 PM Time spent in user mode 0 Days 00:00:13.187 Time spent in kernel mode 0 Days 00:00:00.781 This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required. VCRUNTIME140!MoveSmall+1f0 php7!libiconv_set_relocation_prefix+1928 php7!php_stream_stat_path+10a php7!php_stat+10b php7!php_fputcsv+2215 php7!php_pdo_free_statement+b820 php7!execute_ex+157 php7!zend_execute+159 php7!zend_execute_scripts+119 php7!libiconv_set_relocation_prefix+3443b php+1e2d php+1509 php!php_cli_get_shell_callbacks+589 kernel32!BaseThreadInitThunk+d ntdll!RtlUserThreadStart+34 VCRUNTIME140!MOVESMALL+1F0 In php__PID__5060__Date__09_22_2017__Time_03_05_37PM__264__Second_Chance_Exception_C0000005.dmp the assembly instruction at VCRUNTIME140!MoveSmall+1f0 in C:\Windows\System32\VCRUNTIME140.dll from Microsoft Corporation has caused an access violation exception (0xC0000005) when trying to read from memory location 0x0ce6b000 on thread 0 I may be able to get a compiler installed on the server if there's any other useful information that we could get from it. ------------------------------------------------------------------------ [2017-08-21 09:12:50] ab@php.net Thanks for the BT. I still stuck reproducing this, neither with an older 7.2 binary nor with just freshly compiled one :( Were you using the debug symbols? Also maybe you could try some latest snapshot or beta3. Thanks. ------------------------------------------------------------------------ [2017-08-15 10:17:21] trpro at gmx dot de This is the report from my local pc: In php__PID__188__Date__08_15_2017__Time_08_53_35AM__162__Second_Chance_Exception_C0000005.dmp the assembly instruction at VCRUNTIME140!memmove+4e in C:\Windows\System32\VCRUNTIME140.dll from Microsoft Corporation has caused an access violation exception (0xC0000005) when trying to read from memory location 0x04840000 on thread 0 Thread 0 - System ID 10672 Entry point php!php_cli_get_shell_callbacks+500 Create time 15.08.2017 08:53:33 Time spent in user mode 0 Days 00:00:00.015 Time spent in kernel mode 0 Days 00:00:00.015 This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required. VCRUNTIME140!memmove+4e php7!libiconv_set_relocation_prefix+950 php7!php_stream_stat_path+e6 This is the report from my test VM: Thread 0 - System ID 1372 Entry point php!php_cli_get_shell_callbacks+500 Create time 15.08.2017 08:57:12 Time spent in user mode 0 Days 00:00:00.000 Time spent in kernel mode 0 Days 00:00:00.015 This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required. VCRUNTIME140!memmove+250 php7!php_stream_stat_path+e6 ------------------------------------------------------------------------ [2017-08-14 13:14:07] ab@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. No reproduce on my side as well, checked on win10 and win7. Maybe there'll be more info if you could supply a dump or at least a backtrace. Thanks. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=75074 -- Edit this bug report at https://bugs.php.net/bug.php?id=75074&edit=1

« previous php.bugs (#211415) next »