php / php/php-src

Segfault with observer API on max execution time during php -r

Open
#8,581 6 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Bug Category: Engine Status: Verified
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.