Repository navigation
Crashes due to ex->opline being null #9933
Description
Description
I've noticed some crashes in zend_mm_safe_error() due to ex->opline being null in zend_get_executed_lineno().
ex->opline is normally set by SAVE_OPLINE() in opcode handlers, but some opcode handlers do not call SAVE_OPLINE() when it may be necessary.
PHP Version
PHP 8.0
Operating System
No response
Activity
[-]Crashes de to ex->opline being null[/-][+]Crashes due to ex->opline being null[/+]arnaud-lb commentedon Nov 11, 2022
#9934 demonstrates this by always calling zend_get_executed_lineno() in emalloc().
I'm not sure how to fix this.
I believe that we want to avoid calling SAVE_OPLINE() as much as possible for performance reasons, so one of the only solutions may be to carefully add SAVE_OPLINE() calls where necessary. Maybe we could use some static analysis to help with this.
Alternatively, we could change zend_get_executed_lineno() so that it handles null ex->oplines.
iluuu1994 commentedon Nov 11, 2022
I think this might be the best option. Line numbers for out-of-memory errors might not be very helpful anyway since they will usually be random. If we still want to catch these cases, we could add a
ZEND_ASSERTtozend_get_executed_linenofor debug builds.bwoebi commentedon Nov 11, 2022
I think so too - it should be good enough to default to the first opline of a function, if ex->opline is NULL, I think.
At least currently, it's just the last SAVE_OPLINE() call, and if it's NULL, it should be assumed the first.
Fallback to first line of function when ex->opline is NULL (#10003)