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.

Sign up for GitHub

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

Jump to bottom

Crash with the example from the readme #68

Open
arturoc opened this issue Mar 7, 2017 · 10 comments · Fixed by rust-lang/rust#40367
Open

Crash with the example from the readme #68

arturoc opened this issue Mar 7, 2017 · 10 comments · Fixed by rust-lang/rust#40367

Comments

@arturoc
Copy link

arturoc commented Mar 7, 2017 •
edited
Loading

When running the example from the readme or anything else that uses libfringe like tokio-fibers i'm getting a segmenetation fault. Here's the stacktrace

#0  0x000055555555e5a1 in fringe::arch::imp::init::trampoline_2 ()
    at /home/arturo/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/fringe-1.2.1/src/arch/x86_64.rs:115
#1  0x00007fffffffd420 in ?? ()
#2  0x000055555555e592 in fringe::arch::imp::init::trampoline_1 ()
    at /home/arturo/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/fringe-1.2.1/src/arch/x86_64.rs:60
#3  0x000055555555c420 in ?? () at /checkout/src/libcore/option.rs:157
#4  0x0000000000000000 in ?? ()
@whitequark
Copy link
Contributor

(Not related to actual bug: in the future, please surround stacktraces in ``` ``` when you post them; now this issue is linked back from the first four issues in the repository.)

@arturoc
Copy link
Author

arturoc commented Mar 7, 2017

ugh sorry, i've just edited it

@whitequark
Copy link
Contributor

Unfortunately GitHub doesn't ever remove these backlinks, hence "in the future".

@arturoc
Copy link
Author

arturoc commented Mar 7, 2017

i know, don't even know how i forgot to use the code fence, sorry again

@edef1c
Copy link
Owner

edef1c commented Mar 7, 2017

Can you reproduce this with current master? We're fixing a bunch of plumbing issues and unsafety that got into 1.x right now, and I'm working on releasing 2.0.0 soon.

@edef1c
Copy link
Owner

edef1c commented Mar 7, 2017

Okay, can reproduce with the branch I'm working on. Welp.

@edef1c
Copy link
Owner

edef1c commented Mar 8, 2017

After spending a while in confusion, I've figured out what's up:

(rr) x/2i $pc-1
   0x5619a1b72a20 <fringe::arch::imp::init::trampoline_2>:	jmp    0x5619a1b72a22 <fringe::arch::imp::init::trampoline_2+2>
   0x5619a1b72a22 <fringe::arch::imp::init::trampoline_2+2>:	nop

I'm not sure how this jmp is being generated - it's definitely not from our assembly. We add 1 byte to the instruction pointer to skip over this nop, but because of the jmp everything decodes rather differently, producing the segfault:

(rr) x/2i $pc
=> 0x5619a1b72a21 <fringe::arch::imp::init::trampoline_2+1>:	add    %dl,0x102454ff(%rax)
   0x5619a1b72a27 <fringe::arch::imp::init::trampoline_2+7>:	retq

Still unsure why all the libfringe tests are working given all this..

@edef1c
Copy link
Owner

edef1c commented Mar 8, 2017 •
edited
Loading

The tests are passing because we build them with optimisations, causing rustc to eliminate the extra jmp.
I can either do an awful workaround, or I can wait for this to be fixed in rustc, since it should not be generating code into naked functions, and @eddyb is already working on a rustc patch.

@whitequark
Copy link
Contributor

@edef1c Just add a nopsled there.

@edef1c
Copy link
Owner

edef1c commented Mar 8, 2017 •
edited
Loading

@whitequark already did that, but there's more broken stuff (unwinding doesn't find a landing pad) - though maybe I can solve that with even more nops?
Either way, fixing this in rustc fixes it for all arches, and imo this is broken #[naked] behaviour.

@eddyb eddyb mentioned this issue Mar 8, 2017
Merged
arielb1 pushed a commit to arielb1/rust that referenced this issue Mar 9, 2017
Rollup merge of rust-lang#40367 - eddyb:naked-cruft, r=nagisa
72fc6d4 
Improve the LLVM IR we generate for trivial functions, especially #[naked] ones.

These two small changes fix edef1c/libfringe#68:
* Don't emit ZST allocas, such as when returning `()`
* Don't emit a branch from LLVM's entry block to MIR's `START_BLOCK` unless needed
  * That is, if a loop branches back to it, although I'm not sure that's even valid MIR
alexcrichton added a commit to alexcrichton/rust that referenced this issue Mar 10, 2017
@alexcrichton
Rollup merge of rust-lang#40367 - eddyb:naked-cruft, r=nagisa
d63bbef 
Improve the LLVM IR we generate for trivial functions, especially #[naked] ones.

These two small changes fix edef1c/libfringe#68:
* Don't emit ZST allocas, such as when returning `()`
* Don't emit a branch from LLVM's entry block to MIR's `START_BLOCK` unless needed
  * That is, if a loop branches back to it, although I'm not sure that's even valid MIR
alexcrichton added a commit to alexcrichton/rust that referenced this issue Mar 10, 2017
@alexcrichton
Rollup merge of rust-lang#40367 - eddyb:naked-cruft, r=nagisa
ecdf28c 
Improve the LLVM IR we generate for trivial functions, especially #[naked] ones.

These two small changes fix edef1c/libfringe#68:
* Don't emit ZST allocas, such as when returning `()`
* Don't emit a branch from LLVM's entry block to MIR's `START_BLOCK` unless needed
  * That is, if a loop branches back to it, although I'm not sure that's even valid MIR
alexcrichton added a commit to alexcrichton/rust that referenced this issue Mar 11, 2017
@alexcrichton
Rollup merge of rust-lang#40367 - eddyb:naked-cruft, r=nagisa
97b7de6 
Improve the LLVM IR we generate for trivial functions, especially #[naked] ones.

These two small changes fix edef1c/libfringe#68:
* Don't emit ZST allocas, such as when returning `()`
* Don't emit a branch from LLVM's entry block to MIR's `START_BLOCK` unless needed
  * That is, if a loop branches back to it, although I'm not sure that's even valid MIR
arielb1 pushed a commit to arielb1/rust that referenced this issue Mar 11, 2017
Rollup merge of rust-lang#40367 - eddyb:naked-cruft, r=nagisa
6214e1a 
Improve the LLVM IR we generate for trivial functions, especially #[naked] ones.

These two small changes fix edef1c/libfringe#68:
* Don't emit ZST allocas, such as when returning `()`
* Don't emit a branch from LLVM's entry block to MIR's `START_BLOCK` unless needed
  * That is, if a loop branches back to it, although I'm not sure that's even valid MIR
bors added a commit to rust-lang/rust that referenced this issue Apr 13, 2017
@bors
Auto merge of #40367 - eddyb:naked-cruft, r=nagisa
43ef63d 
Improve the LLVM IR we generate for trivial functions, especially #[naked] ones.

These two small changes fix edef1c/libfringe#68:
* Don't emit ZST allocas, such as when returning `()`
* Don't emit a branch from LLVM's entry block to MIR's `START_BLOCK` unless needed
  * That is, if a loop branches back to it, although I'm not sure that's even valid MIR
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Improve the LLVM IR we generate for trivial functions, especially #[naked] ones. eddyb/rust
3 participants
@arturoc @edef1c @whitequark