Crash in Xlib_xcb in release

[kvark]

Repro case on Linux:

git clone https://github.com/gfx-rs/gfx -b pre-ll
cd gfx
cargo run --release --example terrain

[francesca64]

I'm not able to reproduce this. Can you give more information?

[kvark]

Interestingly, neither do I!

[kvark]

Looks like another repro case here kvark/vange-rs#38

[ia0]

I had the same issue with cargo run --bin=triangle --release in https://github.com/vulkano-rs/vulkano-examples and ran cargo update which fixed the issue. Here is the output of cargo update:

    Updating registry `https://github.com/rust-lang/crates.io-index`
      Adding bitflags v1.0.1
    Updating byteorder v1.1.0 -> v1.2.1
    Updating cc v1.0.0 -> v1.0.3
    Updating cmake v0.1.26 -> v0.1.29
    Removing conv v0.3.3
    Updating core-foundation v0.4.4 -> v0.4.6
    Updating core-foundation-sys v0.4.4 -> v0.4.6
    Removing custom_derive v0.1.7
    Updating dwmapi-sys v0.1.0 -> v0.1.1
    Updating either v1.2.0 -> v1.4.0
    Updating fnv v1.0.5 -> v1.0.6
      Adding fuchsia-zircon v0.3.2
      Adding fuchsia-zircon-sys v0.3.2
    Removing futures v0.1.16
    Updating gdi32-sys v0.1.1 -> v0.1.2
    Removing lazy_static v0.2.8
      Adding lazy_static v0.2.11
      Adding lazy_static v1.0.0
    Updating libc v0.2.31 -> v0.2.34
    Removing magenta v0.1.1
    Removing magenta-sys v0.1.1
    Updating num-rational v0.1.39 -> v0.1.40
    Updating num-traits v0.1.40 -> v0.1.41
    Updating num_cpus v1.6.2 -> v1.8.0
    Updating rand v0.3.16 -> v0.3.19
    Updating rayon-core v1.2.1 -> v1.3.0
    Updating redox_syscall v0.1.31 -> v0.1.33
    Updating scoped_threadpool v0.1.7 -> v0.1.8
    Updating scopeguard v0.3.2 -> v0.3.3
    Updating shared_library v0.1.7 -> v0.1.8
    Updating shell32-sys v0.1.1 -> v0.1.2
    Updating user32-sys v0.1.2 -> v0.1.3
    Updating vk-sys v0.3.1 -> v0.3.2
    Updating vulkano v0.7.1 -> v0.7.2
    Updating vulkano-shader-derive v0.7.1 -> v0.7.2
    Updating vulkano-shaders v0.7.1 -> v0.7.2
    Updating vulkano-win v0.7.1 -> v0.7.2
    Updating x11-dl v2.15.0 -> v2.17.2

[francesca64]

I've also had issues in the past with illegal instructions when running in release mode, which ended up going away after updating. Since multiple people have had this issue, and the solution is rather opaque, would it be good to document this in some way?

[kvark]

@francesca64 I think it's hard to make conclusions (and thus - recommendations) without full-on investigation on what was wrong and why it went away...

[pengowen123]

I had a problem with illegal instructions when using winit and gfx in release mode on nightly, so I use stable now to avoid it.

[ia0]

@kvark It depends conclusions about what. We don't have conclusions about the root cause of the issue. But we apparently have conclusions about the consequences and the frequency of the issue symptoms. I agree that it would be interesting to understand the root cause and properly fix the issue (which requires someone investing time in it). But in the meantime, if the issue is not anecdotal (which doesn't seem to be the case apparently), then I believe that a mitigation solution (like what @francesca64 suggests: documenting the cargo update trick in some troubleshooting section of the documentation) could be useful. Maybe this issue is actually enough if it gets highly ranked by search engines.

I don't know if there is enough information in my cargo update dump above to help someone reproduce the issue and investigate. But it could be a starting point.

[GabrielMajeri]

@ia0 the only relevant crate in your cargo update is x11-dl, since that's what interacts with Xlib (the other crates are either Mac or Windows specific, or not related to windowing).

The only relevant change between v2.15.0 and v2.17.2 is this commit, which fixes some undefined behavior with library loading. That bug was causing crashes on nightly Rust.

The issue @kvark linked is about crashing when opening the library, so that is probably the cause.
@pengowen123 mentioned this was nightly-specific, this matches up with the bug mentioned above.

Best course of action is to update dependencies.

[ia0]

@GabrielMajeri Thanks for having taken the time to look into this issue!

[OvermindDL1]

Running the latest amethyst project example gave me this same issue on nightly in --release mode only, debug works and stable works for both debug and release. No amount of cargo update and so forth did anything to help the issue. I can probably still reliably replicate the issue if required, though considering it's nightly...

[mickvangelderen]

I ran into this issue again with winit 0.18.1, rust nightly-2019-07-19. The same code works on nightly-2019-07-03.

[jdm]

That is likely caused by AltF02/x11-rs#99.

[mateon1]

I ran into this issue when manually building Servo, which uses winit 0.19.1. This seems to be caused by the mem::uninitialized() refactor in the rust stdlib (rust-lang/rust#62150).

See: AltF02/x11-rs#99

This seems to be caused by improper use of mem::uninitialized in x11-rs:

https://github.com/erlepereira/x11-rs/blob/8fb54869045a026dbe14f3c9710b86401eb3e2ef/x11-dl/src/link.rs#L58-L63