Skip to content

assert! terminates rusti REPL #5774

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants