From 145124eb7b5511c16d678e4613ab9779ad424223 Mon Sep 17 00:00:00 2001 From: Edmond <1571649+edmonddantes@users.noreply.github.com> Date: Thu, 20 Aug 2026 11:02:48 +0000 Subject: [PATCH] #256: drop the stale --XFAIL-- from 030-submit_closure_class_return_type The section predicted a use-after-free when a Closure is returned from a worker. The test passes: 20 runs of 20, and three under valgrind with no invalid read. While the section stood, the suite reported a warning on every run and a real regression in that path would have been recorded as an expected failure. --- .../030-submit_closure_class_return_type.phpt | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/tests/thread_pool/030-submit_closure_class_return_type.phpt b/tests/thread_pool/030-submit_closure_class_return_type.phpt index 49bc211a..cfe31f0d 100644 --- a/tests/thread_pool/030-submit_closure_class_return_type.phpt +++ b/tests/thread_pool/030-submit_closure_class_return_type.phpt @@ -1,15 +1,5 @@ --TEST-- ThreadPool: closure with class-name return type (regression: arg_info[-1].type not deep-copied) ---XFAIL-- -Returning a Closure from a worker thread is not yet implemented. -The worker creates a per-result closure snapshot in closure_transfer_obj -(TRANSFER branch), but the result-closure's persistent shell ends up -referencing memory in the task snapshot arena, which the worker frees -in thread_pool_worker_handler before the main thread loads the result. -This causes a heap-use-after-free in async_thread_create_closure when -iterating bound_vars on the loading side. Proper support requires the -result-closure snapshot to own its own arena and outlive the task -snapshot until the loading thread consumes it. --SKIPIF--