Comments (14)
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™:
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.
Related Issues (20)
- Missing git tags for releases HOT 1
- modifier remappings via xmodmap are not read with '=XmodifierMap HOT 1
- XRRScreenResources not giving more than one HOT 1
- SHM-MIT extension
- x11 vs x11-dl? HOT 3
- undefined reference to `XOpenDisplay' HOT 1
- Debug implementation for XEvent is unsound
- XCreateIC returns null incorrectly but only if another crate (tempfile) is present HOT 1
- XshmSegmentInfo can't be created and its fields should be public
- unify x11/x11-dl crates with dlib HOT 2
- Can't run test_x11 test of my lib-crate even with xlib feature enabled HOT 6
- X11 build dependency failed. HOT 3
- Xcomposite extension HOT 1
- Xdamage extension HOT 1
- How to use the Xfixes extension? HOT 7
- MacOS Support HOT 3
- I don't know how to use this struct HOT 3
- Can't load shared library on NetBSD
- Missing constant `None`? HOT 3
- Xlib::open takes up a significant amount of the binary HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from x11-rs.