Optimizer incorrectly removing part of the code?

[dpc]

My code behaves differently in debug and release mode. In release mode pressing "y" to confirm exiting the game is going to be incorrectly ignored. From my investigation, it seems some part of the match expression is getting completely removed.

The affected code:

https://github.com/dpc/rhex/blob/issue/src/ui/curses.rs#L1119

Uncommenting the info! on line 1119 makes the game generate correct code even in release mode.

[futex:lab/rust]% rustc --version
rustc 1.2.0-nightly (99c2f77 2015-05-29) (built 2015-05-29)

[eddyb]

Sounds like typical undefined behaviour (coming from an unsafe block, hopefully).
Could you reduce the application (by commenting out unrelated chunks of code) while still retaining the bug?

[dpc]

I have a one unsafe in my whole project that is quite distant from affected code, and there's really not much code interaction with dependencies in that code, except getting a character number from ncurses.

I can try to reduce it, sure.

[eddyb]

@dpc I'd expect the issue to be in one your dependencies that uses unsafe code, rather than in your own project.

[arielb1]

@dpc

could you run your code in debug mode under valgrind? that could possibly give an hint.

[dpc]

@arielb1:

[futex:rhex/rhex] (master!)% valgrind ./target/debug/rhex
==11605== Memcheck, a memory error detector
==11605== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==11605== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==11605== Command: ./target/debug/rhex
==11605== 
==11605== 
==11605== HEAP SUMMARY:
==11605==     in use at exit: 282,430 bytes in 260 blocks
==11605==   total heap usage: 1,289 allocs, 1,029 frees, 529,137 bytes allocated
==11605== 
==11605== LEAK SUMMARY:
==11605==    definitely lost: 0 bytes in 0 blocks
==11605==    indirectly lost: 0 bytes in 0 blocks
==11605==      possibly lost: 1,728 bytes in 3 blocks
==11605==    still reachable: 280,702 bytes in 257 blocks
==11605==         suppressed: 0 bytes in 0 blocks
==11605== Rerun with --leak-check=full to see details of leaked memory
==11605== 
==11605== For counts of detected and suppressed errors, rerun with: -v
==11605== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[arielb1]

Weird. Could you try and reduce that function?

[dpc]

I tried, but it it's highly coupled with the rest of the code, and I'm very short on time.

[steveklabnik]

Without a reproduction, this is going to be basically impossible to fix.

[dpc]

I don't think I'll be able to minimze this, so I'm closing.

[rprichard]

@dpc I reduced your code and filed #26468.

[dpc]

@rprichard : You're awesome!

[dpc]

The original issue is said to be fixed, but I'm experiencing it on the same code.

[dpc]

Ah, so I see it's a llvm problem and I guess llvm on my system does not have a fix.

[dpc]

I have upgraded my F22 to F23, removed all older llvm versions, and the only llvm is:

% llvm-link --version
LLVM (http://llvm.org/):
LLVM version 3.7.0
Optimized build.
Built Sep 20 2015 (22:09:32).
Default target: x86_64-redhat-linux-gnu
Host CPU: ivybridge

I'm still affected. Am I doing something wrong? I have tried tests from #26468, and these seem to work fine for me. :/

[Mark-Simulacrum]

I cannot reproduce this specific issue with the following (in a docker container). I suspect that this is a LLVM 3.7 problem.

[root@58e7e2988bdf rhex]# uname -a
Linux 58e7e2988bdf 4.4.0-67-generic #88-Ubuntu SMP Wed Mar 8 16:34:45 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

(rustup)
[root@58e7e2988bdf rhex]# rustc -vV
rustc 1.17.0 (56124baa9 2017-04-24)
binary: rustc
commit-hash: 56124baa9e73f28c0709e59e74783cf234a978cf
commit-date: 2017-04-24
host: x86_64-unknown-linux-gnu
release: 1.17.0
LLVM version: 3.9

However, with the Fedora dnf installed rust and cargo (see below), I get a segfault upon trying to run the script. I can't seem to get gdb to work, possibly because of the docker container, but I suspect that this is not this bug, and since I can't really prepare any sort of coredump easily using the docker container, I'm not going to open another issue. It's really odd anyway, IMO.

rustc 1.16.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.16.0
LLVM version: 3.9

@dpc I'm going to close this since I can't reproduce your specific failure, but please do ping us if you can still reproduce and we'll reopen.