Segfault with observer API on max execution time during php -r
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 40.4k
- Forks
- 8.1k
- Avg merge
- 2d 13h
- Merged PRs (30d)
- 96
Description
Description
The following command:
sapi/cli/php -n \
-d 'max_execution_time=1' \
-d 'zend_test.observer.enabled=1' \
-d 'zend_test.observer.observe_all=1' \
-r 'echo "test\n"; crc32("test"); for (;;) {}'
Resulted in this output:
<!-- init 'Command line code' -->
<file 'Command line code'>
test
Fatal error: Maximum execution time of 1 second exceeded in Command line code on line 1
zsh: bus error sapi/cli/php -n -d 'max_execution_time=1' -d 'zend_test.observer.enabled=1' -
The execution results in a bus error instead of a segmentation fault, since the address which is jumped to is not properly aligned. While debugging this I also saw segmentation faults from time to time.
I expect neither a bus error nor a segmentation fault to occur, when executing that command.
Here is the output of lldb:
(lldb) run
Process 92890 launched: '/Users/florian/projects/php/php-src/sapi/cli/php' (arm64)
<!-- init 'Command line code' -->
<file 'Command line code'>
test
Fatal error: Maximum execution time of 1 second exceeded in Command line code on line 1
Process 92890 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=257, address=0x800000017c9e6865)
frame #0: 0xffff80017c9e6865
error: memory read failed for 0xffff80017c9e6800
Target 0: (php) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=257, address=0x800000017c9e6865)
* frame #0: 0xffff80017c9e6865
frame #1: 0x00000001002a9ee0 php`zend_observer_fcall_end(execute_data=0x0000000101212020, return_value=0x0000000000000000) at zend_observer.c:220:3 [opt]
frame #2: 0x00000001002a9fdc php`zend_observer_fcall_end_all at zend_observer.c:240:4 [opt]
frame #3: 0x0000000100192a54 php`php_request_shutdown(dummy=0x0000000000000000) at main.c:1798:3 [opt]
frame #4: 0x00000001002f1a54 php`do_cli(argc=10, argv=0x0000600002600120) at php_cli.c:1135:3 [opt]
frame #5: 0x00000001002f0114 php`main(argc=<unavailable>, argv=<unavailable>) at php_cli.c:1367:18 [opt]
frame #6: 0x00000001005ad088 dyld`start + 516
(lldb) frame select 1
php was compiled with optimization - stepping may behave oddly; variables may not be available.
frame #1: 0x00000001002a9ee0 php`zend_observer_fcall_end(execute_data=0x0000000101212020, return_value=0x0000000000000000) at zend_observer.c:220:3 [opt]
217
218 zend_observer_fcall_end_handler *possible_handlers_end = handler + zend_observers_fcall_list.count;
219 do {
-> 220 (*handler)(execute_data, return_value);
221 } while (++handler != possible_handlers_end && *handler != NULL);
222
223 if (first_observed_frame == execute_data) {
The output was generated on the current PHP-8.1 branch (commit dd89acaf4985fa21ebd6cc9b09615ef6b0a719fc).
So far I only was able to reproduce the problem with php -r – not by executing a PHP file.
PHP Version
PHP 8.1.7
Operating System
Mac OS X 12.3.1 (ARM)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the failure with the provided sapi/cli/php -r command and inspect the observer callback path in zend_observer.c, especially zend_observer_fcall_end(), together with php_request_shutdown() in main.c. Compare the php -r behavior with execution from a PHP file; done means the command terminates without a bus error or segmentation fault.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, php
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100