Bug #77194 [Com]: php7ts.dll crashing when running embed

From: Date: Fri, 11 Oct 2019 23:59:53 +0000
Subject: Bug #77194 [Com]: php7ts.dll crashing when running embed
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-223181@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=77194&edit=1

 ID:                 77194
 Comment by:         jake at qzdesign dot co dot uk
 Reported by:        svbussww at 126 dot com
 Summary:            php7ts.dll crashing when running embed
 Status:             Open
 Type:               Bug
 Package:            Reproducible crash
 Operating System:   Windows 7
 PHP Version:        7.2.12
 Block user comment: N
 Private report:     N

 New Comment:

I think there is a heap corruption issue in PHP, at least in the Windows (x64) build.

I've got some complex tests (running via PHPUnit), and I hit this issue almost every time. 
Sometimes the tests will run to completion, but most times they'll crash at some different
point.  It will be an APPCRASH at one of about three or four apparently random points in the
process.  And always at the same address in php7ts.dll.

As I'm sure you can understand, it's difficult to isolate this further.  I can confirm it
happens with both PHP 7.1.30 and 7.3.4.

This is further frustrated by a Windows 10 update (yes, I know, we need to stop these forced updates
from Microsoft, but easier said than done) to version 1903 (18362.418) which appears to silence
APPCRASH: it no longer appears in the Event Log, and Composer is unable to detect the 'return
value' exception code but is forced to exit silently itself.

Any suggestions on how to restore logging of APPCRASH events since this latest Microsoft atrocity
would be welcomed...


Previous Comments:
------------------------------------------------------------------------
[2019-02-14 18:13:00] ab@php.net

I don't think the patch is the right solution to this after all. The issue seems to be very
specific and affect some specific system configuration. In fact, i couldn't confirm there are
issues with the memory manager. The change as in the patch would introduce memory fragmentation in
opposite to VirtualAlloc, which would affect performance. 32-bit might be well more affected, but
from the backtraces the build used seems to be actually 64-bit. Given Windows 7 reaches EOL in less
than a year and such issues are not massively reported, probably the issue is a low priority.

Thanks.

------------------------------------------------------------------------
[2019-01-22 08:08:51] jr at concept-br dot de

Change from 32 build to 64 build (Apache + PHP) >> Works like a charm!

------------------------------------------------------------------------
[2018-12-09 17:02:50] ab@php.net

@jr at concept-br dot de, please post a backtrace.

Thanks.

------------------------------------------------------------------------
[2018-12-07 11:01:55] jr at concept-br dot de

Same Problem here also in 7.2.13 on Windows Server 2012 R2. We restart the apache service every hour
to "workaround" until a bugfix is released

------------------------------------------------------------------------
[2018-11-29 16:49:12] svbussww at 126 dot com

I have uploaded a fix.
Use _aligned_malloc and _aligned_free instead of unreliable VirtualAlloc and VirtualFree

------------------------------------------------------------------------


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=77194


--
Edit this bug report at https://bugs.php.net/bug.php?id=77194&edit=1


Thread (22 messages)

« previous php.bugs (#223181) next »