GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||
GeezerVison is showing github.com — Zend: user opcode DISPATCH runs on a stale frame in the TAILCALL VM. by devnexen · Pull Request #24109 · php/php-src Conversation
Member
Fix #24081 ZEND_VM_DISPATCH() ran the CALL variant of the handler and returned its next opline to execute_ex(), whose execute_data still pointed at the entry frame. It now tail calls the TAILCALL variant of the handler.
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page. All reactionsFix php#24081 ZEND_VM_DISPATCH() ran the CALL variant of the handler and returned its next opline to execute_ex(), whose execute_data still pointed at the entry frame. It now tail calls the TAILCALL variant of the handler.
arnaud-lb
approved these changes
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Looks good to me!
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page. All reactions
Member
All reactions
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page.
Member
All reactions
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page.
|
There was an error while loading. Please reload this page.
|
I think can be fixed with |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
#280) php/php-src#24109 (merged into PHP-8.6 as 2cf7ad0) makes the generated ZEND_USER_OPCODE_SPEC_TAILCALL_HANDLER resume the DISPATCH result inside the tail-call chain instead of returning it to execute_ex()'s stale frame, so OpCode::setHandler() no longer needs to refuse on VM_KIND_TAILCALL. Remove the guard, its exception factory, the issue-280 probe ladder and the dispatch-only diagnose workflow; keep Core::vmKind() as plain engine introspection, and keep the every-leg hook coverage the guard test introduced as OpCodeHookLifecycleTest (the gap that let #280 ship unnoticed was that all other hook tests are internal-group only). Docs now record the bug as fixed upstream rather than as a live caveat. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01U4cKi87mVQ896uSrw592fG
… fixed php-src fixed the user-opcode dispatch under the tail-call VM (lisachenko/z-engine#280, resolved by php/php-src#24109 merged into PHP-8.6), and current 8.6 nightlies run engine hooks cleanly on Apple Silicon, so the experimental escape hatch comes off: the arm64 + 8.6 leg fails the workflow like every other leg again. Docs record the bug as fixed instead of as a platform exception. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01U4cKi87mVQ896uSrw592fG
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
[Bug] User opcode handlers resume execution against a stale frame under ZEND_VM_KIND_TAILCALL
There was an error while loading. Please reload this page.