Illegal instruction in nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.29.0-nightly (866a71325 2018-07-29) about x11-rs HOT 14 CLOSED

hey, we're in an unsafe block, so expect and allow unsafe things to occur.

That's not what an unsafe block means. You still have to follow the same rules, but rustc isn't checking whether you do or not. If LLVM is told a type is not going to be zero, and code explicitly writes a zero to it, it can assume that code is unreachable, and compile it into an abort to reduce code size.

from x11-rs.

This is because of my abomination that is the x11_link! macro. In an old version of the macro, it loaded the library in a single pass instead of a loop (IIRC), but for some reason it was causing stack overflows that appeared to be a rustc bug. Enormous structs on the stack are a pain to work with when stack size is so limited, but afaik we still don't have the box keyword.

I find it unpleasantly surprising that a language marketed toward kernel writers is making it increasingly harder to directly operate on memory.

Edit: ~~~I just read #91, and this seems like the only possible fix that doesn't break backwards compatibility.~~~

from x11-rs.

It looks like they've re-opened 52898. This was a breaking change in rustc and contradicts the docs, and I really hope they revert it.

from x11-rs.

Looks like #91 fails to build on my system, probably because generating a behemoth function requires more RAM than the 4 GiB on my laptop. This seemed like the only thing that would work. I'm seriously out of ideas unless the rust devs decide to revert this unacceptable regression in the compiler.

from x11-rs.

If LLVM is told a type is not going to be zero, and code explicitly writes a zero to it, it can assume that code is unreachable, and compile it into an abort to reduce code size.

This is the first time I've read a good explanation. In the thread for the issue in the rust compiler, people just said "undefined behavior" and made no explanation of how it's different from uninitialized. Thanks!

from x11-rs.

Bug fixed in 2.18.3. Good work!

from x11-rs.

I believe this won't be fixed in the compiler (as apparently the compiler is doing The Right Thing™:

rust-lang/rust#52898

from x11-rs.

Yeah I'm hitting this recently as well. The referenced rust ticket says it's because some unsafe block has some undefined behaviour regarding a zero-value reference, which is illegal.

from x11-rs.

FYI, Bug still open in x11-dl 2.18.2

from x11-rs.

While I'm all for strong defined behaviour, I think this one was rushed.

Can you try, er, negotiate at least a "stopgap revert" until a graceful way out is found?

from x11-rs.

This is caused by a change in rustc, so I don't know what to do unless they revert that change (which it's looking more likely that they will). #91 reverts x11-dl to loading libraries like it did something like 2 years ago, and it's not even building on my system anymore. I can try using mem::uninitialized instead of mem::zeroed, as someone suggested that it doesn't have the same level of undefined behavior (which makes no sense to me, but whatever), but I'm not sure it will fix anything. I'll make the change now.

from x11-rs.

Coyboy fix published. Lmk if it works (the bug wasn't occurring on my system, so I can't test that).

from x11-rs.

2.18.3 fixes it for me.

I can try using mem::uninitialized instead of mem::zeroed, as someone suggested that it doesn't have the same level of undefined behavior (which makes no sense to me, but whatever)

The undefined behavior is writing a zero to a function pointer, because a function pointer is not allowed to be zero. uninitialized does not write anything to it at all.

from x11-rs.

That makes sense, but it seems very odd to me that their solution was raise SIGILL, causing existing code to now break instead of hey, we're in an unsafe block, so expect and allow unsafe things to occur, especially when the uninitialized/zeroed value is replaced with something valid before ever being used.

from x11-rs.