PHP :: Bug #76590 :: Using persistent strings as HashTable keys causes heap corruption

[2018-07-06 15:38 UTC] dktapps at pmmp dot io

Description:
------------
While attempting to update ext/pthreads (Using the master branch of https://github.com/krakjoe/pthreads) for PHP 7.3.0 alphas, I encountered a range of heap corruption issues.

After extensive debugging, I discovered these issues were not caused by pthreads itself. These issues were caused by this commit: https://github.com/php/php-src/commit/5eb1f92f31cafc48384f9096012f421b37f6d425

To be specific, using persistent strings as hashtable keys now causes issues with heap corruption in "zend_array_destroy()" because it now assumes that keys are always non-persistent. pthreads then suffered from issues due to using persistent strings as htable keys for object property tables.

I have not further investigated the range of things that this affected.

Test script:
---------------
<?php

$worker = new Worker();
$worker->start();
$worker->stack(new Threaded);
$worker->shutdown();

?>

Expected result:
----------------
no output

Actual result:
--------------
zend_mm_heap corrupted

or if in debug mode:

Assertion failed: !(zval_gc_flags((s)->gc.u.type_info) & (1<<7)), file c:\php-sdk\php\vc15\x64\php-src\zend\zend_string.h, line 290

[2018-07-06 15:51 UTC] nikic@php.net

-Status: Open +Status: Feedback

[2018-07-06 15:51 UTC] nikic@php.net

Placing any kind of persistent entity withing a non-persistent entity (including persistent keys into a non-persistent array) is generally a violation of PHP's memory model. Doing so usually manifests in the form of subtle thread-safety issues caused by non-atomic reference counting. This is also why use of immutablized (persistent) entities is generally legal, as they are not subject to refcounting.

Please explain in more detail (and point to the relevant code), where you are using persistent keys in non-persistent hashtables, and why you believe this to be safe. Most likely you either need to use non-persistent strings or ensure that the strings are interned.

[2018-07-06 16:49 UTC] nikic@php.net

By the way, it may be helpful to run pthreads in ZEND_RC_DEBUG mode, which detects refcount changes on persistent entities after the start of the request cycle. Not sure if this is compatible with the particular magic of pthreads though.

[2018-07-06 17:56 UTC] dktapps at pmmp dot io

-Status: Feedback +Status: Open

[2018-07-06 17:56 UTC] dktapps at pmmp dot io

In several cases persistent strings were used for globals (which it's reasonable to make interned instead), and there was one erroneous case of persistent string used where it shouldn't have been.

I'm still trying to get an idea of the full scope of this as I work through the issues.

There is one thing that I think may be a bug, which is the behaviour of zend_hash_str_update_ptr(). If the array is persistent, the key zend_string created will also be persistent. I hit issues with this because pthreads inserts copied functions into EG(function_table), which is assumed to have non-persistent keys. This is easily worked around though.

Patches

Pull Requests

History

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2020 The PHP Group All rights reserved.	Last updated: Wed Oct 28 16:01:26 2020 UTC