-
Notifications
You must be signed in to change notification settings - Fork 663
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
After actix upgrade, panic are not always properly propagated, and tests that should_panic
fail.
#3901
Comments
should_painc
, in which case they always fail
@frol after looking into it, I observe the following: #3869 updates all the tests except for the ones in
It is consistent with how you updated other tests. With this, when I run the test
This is expected behavior. However, the test doesn't stop and continues running. The panic doesn't propagate, and doesn't cause the test to fail. |
should_painc
, in which case they always failshould_panic
fail.
@matklad do you happen to know what may have caused this? |
This is not a new problem, and we had infrastructure to handle it, but it was (inadvertently?) removed in the linked PR: |
@SkidanovAlex the old way of setting up @bowenwang1996 would you like me to take a look into it? |
@frol the panics are not propagated from child processes. E.g. if you do a |
@SkidanovAlex Thank you for digging into it and providing very specific repro examples. I totally understand the issue. My only question is whether @bowenwang1996 still wants to take care of the issue or should I finish it up. |
@bowenwang1996 no, I don't. I do have a general observation that propagating panics across synchronization points in rust requires some explicit code. One bit of Rust knowledge that might help debug this: Rust panic is a two-stage process. First, the panic hook is invoked at the stack frame where the panic occurs. Then the stack is unwound. The assert message and stack trace are printed in the first phase, not after the stack is unwond. So it indeed might be the case that you see assertion failure, but the panic is swallowed. |
I was mistaken as to why the test was broken, so @frol please take a look |
After #3869,
chunks_recovered_from_full_timeout_too_short
fails, which is likely related to the block timeout we set and the speed up from actix version upgrade.The text was updated successfully, but these errors were encountered: