Skip to content

Conversation

iluuu1994
Copy link
Member

Fixes GH-19844

@nielsdos
Copy link
Member

This looks hacky and will likely cause leaks for resources that were not yet destroyed.

@iluuu1994
Copy link
Member Author

iluuu1994 commented Sep 15, 2025

I'm not sure there are any good solutions for bailout during shutdown. We might minimize leaking by wrapping each resource destructor call in zend_try. I'm open to suggestions.

Also note that it at least does not introduce any new leaks. The current code would already leak if the second attempt to call the destructor bails again.

@arnaud-lb
Copy link
Member

arnaud-lb commented Sep 16, 2025

I agree this is better than before, and this is similar to how we handle bailouts in shutdown_destructors(). However there is more risk of leaking scarce resources (file descriptors) in this case than with destructors, so it may be worth it to try to release them anyway. zend_close_rsrc_list() could wrap the entire loop in zend_try and restart to the next resource after a bailout.

@iluuu1994 iluuu1994 changed the base branch from PHP-8.4 to PHP-8.3 September 17, 2025 14:02
@iluuu1994
Copy link
Member Author

Okay, I adjusted the code to keep closing resources even after bailout, so that the resources don't leak.

@iluuu1994
Copy link
Member Author

Unfortunately the Windows issue is legit, but I don't know what causes it and I don't have a Windows machine to test it.

@arnaud-lb
Copy link
Member

I've tried running the test in a VM, but it passed

@nielsdos
Copy link
Member

That termsig code converts to 0xc00000ff in hex. That means STATUS_BAD_FUNCTION_TABLE. Prediction: if you run CI without JIT, issue disappears?
Can't check now as I have no dev machine at hand

@nielsdos
Copy link
Member

nielsdos commented Oct 8, 2025

FWIW I can reproduce the issue with a release build on Windows,~~ even without this PR but with the test in this PR. Doesn't even need JIT/opcache.~~ EDIT: no wait, it does need the patch, this is über confusing.

001- Fatal error: Bail in %s on line %d
002-
003- Fatal error: Bail in %s on line %d
004-
     Fatal error: Bail in C:\php-sdk\phpdev\vs17\x64\php-src\x.php on line 22
002+
003+ Termsig=-1073741784

@nielsdos
Copy link
Member

nielsdos commented Oct 8, 2025

For some reason it works when you don't remove the try-catch in zend_execute_API.c...

@iluuu1994
Copy link
Member Author

So, goto misoptimization or something?

@nielsdos
Copy link
Member

nielsdos commented Oct 8, 2025

So, goto misoptimization or something?

I thought that first too.
It already failed in CI for some reason, even though the while loop works on my machine... I'll try pushing the one where we undo the zend_try in zend_execute_API.c

@nielsdos
Copy link
Member

nielsdos commented Oct 8, 2025

Alternatively if looping / goto is an issue, zend_try around the zend_resource_dtor call itself could also work (but may be more performance hungry).

@iluuu1994
Copy link
Member Author

Seems like neither worked... If this is an existing issue, maybe it's ok to skip the test on Windows?

@nielsdos
Copy link
Member

nielsdos commented Oct 9, 2025

Seems like neither worked... If this is an existing issue, maybe it's ok to skip the test on Windows?

This sucks, because reproducing it is also flaky. Yesterday it seemed like it is pre-existing but now it doesn't reproduce anymore. I'll try to have one more look again under a debugger in the hopes I can figure out why it is failing.

@iluuu1994
Copy link
Member Author

Thanks for your effort! I was just asking because I'm unable to help. :) But if you prefer we can wait until the issue is solved.

@nielsdos
Copy link
Member

nielsdos commented Oct 9, 2025

No dice... It just stops reproducing when trying to debug it. 🤷

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants