-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
assert! terminates rusti REPL #5774
Comments
I investigated this for a bit, and I came up with this test case causing the same behavior: fn main() { assert!(false); } And then running It appears that when failure is generated the c++ exception isn't caught in the normal spot. I know very little about C++ exceptions, but this definitely has something to do with LLVM and JIT code. I googled around and found a very similar problem in a few different spots. They all pointed to the same answer of enabling exception handling during JIT code generation, but rust definitely does that, so I think that something else is going wrong here. I guess this could be an LLVM bug, but I doubt that. I figured I'd post my findings here anyway. |
These few commits address a few existing issues: * #5469 - adding regression tests for `rusti`. This adds unit tests to the `rusti.rc` file (which needed some reorganization of the Makefile, see the first commit message). These are super-simple right now, and sadly can't test the output of the tests. I worked for a bit on making a compiletest version of the rusti tests, but I ended up hitting something which blocked me, although I've forgotten it by this point. * #5937 - regression test added, and it's fixed * #5803 - just doesn't appear to happen any more * #5784 - it's no longer broken, and it no longer spits out warnings about unused variables. I also did some investigation into #5774, and you may want to read the comment I left on the bug. The gist of the situation is that C++ exceptions across JIT code don't look like they're working, even though they [should be working](https://github.com/mozilla/rust/blob/3aa1122ec25d15a2a73a295f8298ad9c38b09a10/src/rustllvm/RustWrapper.cpp#L387). If anyone has any insight on this, that would be awesome!
@alexcrichton this isn't fixed, but #7115 seems to have landed. |
Actually I take that back my rustc might not be new enough.. |
With the llvm upgrade, I still see an abort on failure. I don't think assert is different from plain fail!
|
I specifically remember this being fixed at some point, although we may not have pulled in enough LLVM fixes to make it a thing. Regardless, yes, this was not fixed by #7115 and may need more LLVM patches, but we may have regressed to the point that it's our problem now as well. |
@blake2-ppc, that looks like the same failure as before though. Basically the JIT code is emitted in such a way that you can't throw an exception from one end to the other. The jit code is calling out into C++ which is thrown an exception to terminate the task, but the C++ code on the other side of the JIT code isn't catching it. As soon as I can get a building rust with LLVM-head I'll see if this is fixed on it. |
Fix FP in `new_ret_no_self`: trigger in trait def instead of impl block Lint in trait def instead of impl block. Fixes: rust-lang#5435 changelog: none
Perhaps this is expected behavior in order to maintain consistency, but, as a newcomer to rust, this surprised me, and it seems mildly inconvenient.
rusti> assert!(false); rust: task failed at 'assertion failed: false', <anon>:34 terminate called throwing an exception Abort trap: 6
By comparison, other languages I'm familiar with throw an error and then return you to the REPL:
Scala:
scala> assert (false) java.lang.AssertionError: assertion failed ... scala>
Ocaml:
utop $ assert(0 == 1);; Exception: (Assert_failure //toplevel// 1 0) utop $
Python:
p> assert(0) Traceback (most recent call last): File "<stdin>", line 1, in <module> AssertionError p>
The text was updated successfully, but these errors were encountered: