PHP 7.3 Compatibility #364
Conversation
|
All tests in Appveyor passed: https://ci.appveyor.com/project/stesie/v8js/build/1.0.263 |
|
Hey @Jan-E, thanks for the effort you've put into this. I've briefly tried it out, first on my NixOS box ... and then on Ubuntu Xenial to confirm, ... there seems to be a memory issue in the code path handling V8 extensions, as those two tests fail: ... they don't directly "fail" but crash the interpreter on shutdown. I'm unsure if this also happens on Windows yet unnoticed by the test runner since the output is actually correct I'll dig deeper soon, maybe tonight ... likely first build with address sanitizer or so, since the current backtraces that just crash in |
|
I ran directly and php.ini is Then I also experienced a
|
|
The output window in the debugger only mentions |
|
With the same extension sources and the same V8-dll's the crash does not happen on PHP 7.2.8 RC1. So it really is PHP 7.3 specific. @cmb69 Any idea? |
|
Or @remicollet ? |
|
Simplest test script. php.ini basic_test.php Run: And fwiw: recompiling with V8-5.8.283.31 did not make any difference |
|
On July 4 & 5 @dstogov did a lot of work on zval_dstor and zval_ptr_dstor: See for instance 'Use zval_ptr_dtor() imstead of zval_dtor()': zval_dtor is used in v8js_array_access_dispatch: Could this be related? |
|
See m6w6/ext-http#78 (comment) as well. And the commit m6w6/ext-http@377d576 Mayve @dstogov is trying to fix that in master |
|
|
accidentally tripped by a typo: ... but also shouldn't happen :D |
I have seen something like that before:
@remicollet @cmb69 Could this be the same problem? Something wrong with zend_hash_destroy, like it apparently was here as well: |
| if (myht && GC_IS_RECURSIVE(myht)) { | ||
| #else | ||
| if (myht && ZEND_HASH_GET_APPLY_COUNT(myht) > 1) { | ||
| #endif |
There was a problem hiding this comment.
I don't think this is the proper fix,
GC_IS_RECURSIVE is equiv. of ZEND_HASH_GET_APPLY_COUNT(myht) > 0
There was a problem hiding this comment.
oh, indeed. But with the other change the > 1 part is wrong, so the GC_IS_RECURSIVE is right.
This code path is triggered if recursive, non-associative arrays are exported to JavaScript like so:
$a = [];
$a[] = &$a;
$a[] = 23;
$v8 = new V8Js();
$v8->foo = $a;
$v8->executeString('var_dump(PHP.foo);');output on PHP 7.2 now:
array(2) {
[0] =>
array(2) {
[0] =>
NULL
[1] =>
int(23)
}
[1] =>
int(23)
}
output on PHP 7.3 now:
array(2) {
[0] =>
NULL
[1] =>
int(23)
}
|
@Jan-E nah, I don't think so. The point here is that v8js uses interned strings to track loaded extensions (i.e. strings that aren't bound to request cycle, but live until interpreter exit) and puts those into a hash table. PHP 7.2 didn't free those manually constructed interned strings itself, ... with PHP 7.3 that changed, i.e. PHP 7.3 now frees them itself. Hence if this extension continues to free them there's a double free on shutdown |
I do not see this change documented in https://github.com/php/php-src/blob/master/UPGRADING.INTERNALS @cmb69 Shouldn't this be there? |
|
It seems to me that no interned strings are used as of efad52d, but rather some persistent strings. The latter are not touched by the Zend engine, as far as I know. |
|
You might be right on the persistent strings. Still, this commit seems to have solved the heap corruption: aa041b4 So there must be a difference between 7.2 and 7.3. |
|
Yeah, this wasn't the right fix. I've reverted it and tried a different route. When freeing we must make sure the string isn't interned (and simple leave it alone then). If the string however is not interned, but a normal persisten one, then we need to free that. |
Streamlined PR, in stead of #363