Description:
------------
I found sporadic crashes in my application upon max_time_limit exhaustion. They were all somewhere within zend_observer_fcall_end_all.

The crashes are all related to invalid contents within current_observed_frame.

In this specific reproducer I found, the issue is related to attributes, which use a stack allocated dummy frame (notably with ex->func being non-NULL, which is unlike the generator dummy frames).

Test script:
---------------
Using zend_test with INI:
zend_test.observer.enabled=1
zend_test.observer.observe_all=1

<?php

namespace X; // avoid cuf() being optimized away

ini_set("memory_limit", "20M");

#[\Attribute]
class A {
        public function __construct() {}
}

#[A]
function B() {}

$r = new \ReflectionFunction("X\\B");
var_dump(call_user_func([$r->getAttributes(A::class)[0], 'newInstance']));

array_map("str_repeat", ["\xFF"], [100000000]); // cause a bailout

Expected result:
----------------
No crash.

Actual result:
--------------
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x0000000100722f16 php`zend_observer_fcall_end(execute_data=0x00007ffeefbfde70, return_value=0x0000000000000000) at zend_observer.c:211:42
    frame #1: 0x00000001007230a3 php`zend_observer_fcall_end_all at zend_observer.c:243:4
    frame #2: 0x00000001004fd7c5 php`php_request_shutdown(dummy=0x0000000000000000) at main.c:1783:3
    frame #3: 0x00000001007a44d1 php`do_cli(argc=4, argv=0x00007ffeefbff930) at php_cli.c:1135:3
(lldb) p execute_data
(zend_execute_data *) $0 = 0x00007ffeefbfde70 // stack memory