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

internal error: entered unreachable code at semantics/src/traversal/expressions.rs:141:5 #211

Closed
agroce opened this issue Jan 29, 2021 · 13 comments

Comments

@agroce
Copy link

agroce commented Jan 29, 2021

Compiling this file:

contract Foo:
    event MyEvent:
        my_u8s: u8[255]
    pub def set_my_u8s(my_u8s: u8[255]):
        emit MyEvent(self.my_bytes.to_mem)
$ RUST_BACKTRACE=1 target/debug/fe finish.fe 
Warning: bytecode output requires 'solc-backend' feature. Try `cargo build --release --features solc-backend`. Skipping.
thread 'main' panicked at 'internal error: entered unreachable code', semantics/src/traversal/expressions.rs:141:5
stack backtrace:
   0: rust_begin_unwind
             at /rustc/c0b64d97beebb09325b5587abed39f4f1621026f/library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at /rustc/c0b64d97beebb09325b5587abed39f4f1621026f/library/core/src/panicking.rs:92:14
   2: core::panicking::panic
             at /rustc/c0b64d97beebb09325b5587abed39f4f1621026f/library/core/src/panicking.rs:50:5
   3: fe_semantics::traversal::expressions::expr
   4: fe_semantics::traversal::expressions::assignable_expr
   5: fe_semantics::traversal::expressions::call_arg
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Aborted

On latest github master, built with

[profile.dev]
debug = true
panic = "abort"

for fuzzing. Using https://github.com/agroce/afl-compiler-fuzzer (we've found more than 50 bugs (that were worth fixing, and have been fixed) in solc using this afl variant) + afl.rs.

This might be a more interesting type of bug, if you think fe is ready for fuzzing at all.

@g-r-a-n-t
Copy link
Member

Thanks for the report! Will look into these bugs and the fuzzer 😄

@agroce
Copy link
Author

agroce commented Jan 30, 2021

Quick question @g-r-a-n-t -- should I be running the solc backend? I figure you don't totally care about any crashes there, but maybe it malformed or mis-handled YUL would be of interest, whoever's "fault" it is...

@g-r-a-n-t
Copy link
Member

I think that would reveal some meaningful errors. It's possible for us to create Yul code with things like invalid identifiers or missing function parameters. I run into these issues pretty frequently while debugging new features.

Thank you very much for doing this.

@agroce
Copy link
Author

agroce commented Jan 30, 2021

Sure!

@agroce
Copy link
Author

agroce commented Jan 30, 2021

Ok, one is running with the solc backend. Will solc crash, or just fail with an error, if given invalid Yul? If the latter, fuzzing with afl won't catch it without some code changes to the compiler(s).

@g-r-a-n-t
Copy link
Member

Ah, yeah. It will return an error. We should be crashing though.

Opened a PR to fix this and will merge soon.

@g-r-a-n-t
Copy link
Member

merged!

@agroce
Copy link
Author

agroce commented Jan 30, 2021

Great! I'll grab and restart fuzzers later with this. Do you think there's a big overhead for having solc do codegen? Faster fuzzing is better, but if the difference is not too big, maybe just hitting codegen with all runs is worth the hit, to find more problems.

@g-r-a-n-t
Copy link
Member

Hard for me to say.. looks like you've already found some insightful crashes.

@agroce
Copy link
Author

agroce commented Feb 2, 2021

Yeah, I did a little experimenting, and due to almost all runs not getting through the parser, even with our tricks to make that less common, it's basically free, so I just have five running full blast on the whole enchilada.

@agroce
Copy link
Author

agroce commented Feb 2, 2021

I see you all added msg.sender and such, but I'll give these a few days to hammer on the version I started on before switching over. I do a kind of saturation check based on which bugs which fuzzer instances found, and six of the 12 currently being found are only found by one fuzzer run (vs only 3 every fuzzer run has found) so I think it needs a week or so of getting deeper to pull out more subtle stuff.

@agroce
Copy link
Author

agroce commented Feb 5, 2021

Related variant, I believe:

contract Foo:
    pub def foo():
        emit MyEvent("foo", 1000)(0==1)

on latest, code location has moved (but is same as above now produces) but backtrace differs:

thread 'main' panicked at 'internal error: entered unreachable code', analyzer/src/traversal/expressions.rs:142:5
stack backtrace:
   0: rust_begin_unwind
             at /rustc/c0b64d97beebb09325b5587abed39f4f1621026f/library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at /rustc/c0b64d97beebb09325b5587abed39f4f1621026f/library/core/src/panicking.rs:92:14
   2: core::panicking::panic
             at /rustc/c0b64d97beebb09325b5587abed39f4f1621026f/library/core/src/panicking.rs:50:5
   3: fe_analyzer::traversal::expressions::expr_name_string
   4: fe_analyzer::traversal::functions::traverse_statements
   5: fe_analyzer::traversal::functions::func_body
   6: fe_analyzer::traversal::contracts::contract_def
   7: fe_analyzer::traversal::module::module
   8: fe_analyzer::analyze
   9: fe_compiler::compile
  10: fe::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Aborted

cburgdorf added a commit to cburgdorf/fe that referenced this issue Mar 24, 2021
@cburgdorf
Copy link
Collaborator

The original error already has been resolved and the last variant will be fixed by #336

cburgdorf added a commit to cburgdorf/fe that referenced this issue Mar 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants