Skip to content
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

Closed
danluu opened this issue Apr 7, 2013 · 7 comments
Closed

assert! terminates rusti REPL #5774

danluu opened this issue Apr 7, 2013 · 7 comments

Comments

@danluu
Copy link
Contributor

danluu commented Apr 7, 2013

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>

@alexcrichton
Copy link
Member

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 rustc -Z jit ./foo.rs.

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.

bors added a commit that referenced this issue May 14, 2013
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
Copy link
Member

In other news, using the LLVM branch brson/llvm/wip rebased on top of chapuni/llvm/master (yielding my branch) fixes this issue.

This makes me think that it's purely awaiting an LLVM upgrade, or in other words this is blocked on #7115

@emberian
Copy link
Member

emberian commented Aug 5, 2013

@alexcrichton this isn't fixed, but #7115 seems to have landed.

@emberian
Copy link
Member

emberian commented Aug 5, 2013

Actually I take that back my rustc might not be new enough..

@bluss
Copy link
Member

bluss commented Aug 5, 2013

With the llvm upgrade, I still see an abort on failure. I don't think assert is different from plain fail!

$ rusti
WARNING: The Rust REPL is experimental and may be
unstable. If you encounter problems, please use the
compiler instead. Type :help for help.
rusti> fail!(); 1
rust: task failed at 'explicit failure', <anon>:17
terminate called after throwing an instance of 'rust_task*'
Avbruten (SIGABRT)

@alexcrichton
Copy link
Member

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.

@alexcrichton
Copy link
Member

@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.

@bors bors closed this as completed in a8c3fe4 Aug 20, 2013
flip1995 pushed a commit to flip1995/rust that referenced this issue Aug 28, 2020
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants