-
Notifications
You must be signed in to change notification settings - Fork 104
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
RMC doesn't seem to handle stack unwind logic correctly #545
Comments
Note that the cleanup logic seems correct when there is no unwinding: // Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0 OR MIT
#[derive(PartialEq, Eq)]
struct S {
a: u8,
}
impl Drop for S {
fn drop(&mut self) {
assert!(false, "A1: This should still fail during cleanup");
}
}
pub fn main() {
let lhs = S { a: 42 };
let rhs = S { a: 0 };
assert!(lhs != rhs, "A2: A true statement. Succeed");
} Result is:
|
There are actually two different bugs reported in this issue.
We'll handle the bug |
I refactored how we codegen panic statements so it now it terminate the program per its spec. I have also removed the hack we had to try to get the assert location. Since we currently do not support stack unwinding, the panic codegen will always terminate immediately and it will not try to unwind the stack. I added an option to RMC to force the compiler to use abort as the panic strategy and a check to rmc codegen that will fail if the user tries to override that. Another note is that we currently do not support `#[track_caller]` and I have not changed that. This change fixes #67, fixes model-checking#466, fixes model-checking#543, and fixes model-checking#636. This change also mitigates model-checking#545.
I refactored how we codegen panic statements so it now it terminate the program per its spec. I have also removed the hack we had to try to get the assert location. Since we currently do not support stack unwinding, the panic codegen will always terminate immediately and it will not try to unwind the stack. I added an option to RMC to force the compiler to use abort as the panic strategy and a check to rmc codegen that will fail if the user tries to override that. Another note is that we currently do not support `#[track_caller]` and I have not changed that. This change fixes #67, fixes #466, fixes #543, and fixes #636. This change also mitigates #545.
We don't support stack unwinding yet. I created a feature request (#692) to track that. I'll leave this issue open for now since it is a valid use case that we should ensure gets covered. |
I refactored how we codegen panic statements so it now it terminate the program per its spec. I have also removed the hack we had to try to get the assert location. Since we currently do not support stack unwinding, the panic codegen will always terminate immediately and it will not try to unwind the stack. I added an option to RMC to force the compiler to use abort as the panic strategy and a check to rmc codegen that will fail if the user tries to override that. Another note is that we currently do not support `#[track_caller]` and I have not changed that. This change fixes model-checking#67, fixes model-checking#466, fixes model-checking#543, and fixes model-checking#636. This change also mitigates model-checking#545.
I refactored how we codegen panic statements so it now it terminate the program per its spec. I have also removed the hack we had to try to get the assert location. Since we currently do not support stack unwinding, the panic codegen will always terminate immediately and it will not try to unwind the stack. I added an option to RMC to force the compiler to use abort as the panic strategy and a check to rmc codegen that will fail if the user tries to override that. Another note is that we currently do not support `#[track_caller]` and I have not changed that. This change fixes model-checking#67, fixes model-checking#466, fixes model-checking#543, and fixes model-checking#636. This change also mitigates model-checking#545.
I refactored how we codegen panic statements so it now it terminate the program per its spec. I have also removed the hack we had to try to get the assert location. Since we currently do not support stack unwinding, the panic codegen will always terminate immediately and it will not try to unwind the stack. I added an option to RMC to force the compiler to use abort as the panic strategy and a check to rmc codegen that will fail if the user tries to override that. Another note is that we currently do not support `#[track_caller]` and I have not changed that. This change fixes model-checking#67, fixes model-checking#466, fixes model-checking#543, and fixes model-checking#636. This change also mitigates model-checking#545.
I refactored how we codegen panic statements so it now it terminate the program per its spec. I have also removed the hack we had to try to get the assert location. Since we currently do not support stack unwinding, the panic codegen will always terminate immediately and it will not try to unwind the stack. I added an option to RMC to force the compiler to use abort as the panic strategy and a check to rmc codegen that will fail if the user tries to override that. Another note is that we currently do not support `#[track_caller]` and I have not changed that. This change fixes #67, fixes #466, fixes #543, and fixes #636. This change also mitigates #545.
I was playing with the assertion codegen to understand how we were handling cleanup after a failure. I created the following test case:
using the following command line invocation:
I expected to see this happen: Assertions A1 and A2 should fail, but assertions A3 should be unreachable.
Instead, this happened: RMC entered an infinite loop.
I also tested the code with --unwind 0. The result is incorrect. A2 and A3 fail, but A1 doesn't.
The text was updated successfully, but these errors were encountered: