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.

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

Optimizer incorrectly removing part of the code? #25919

Closed
dpc opened this issue May 31, 2015 · 15 comments
Closed

Optimizer incorrectly removing part of the code? #25919

dpc opened this issue May 31, 2015 · 15 comments
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.

Comments

@dpc
Copy link
Contributor

dpc commented May 31, 2015

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)

@dpc dpc changed the title Optimizer error? Optimizer incorrectly removing part of the code? May 31, 2015
@eddyb
Copy link
Member

eddyb commented May 31, 2015

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
Copy link
Contributor Author

dpc commented May 31, 2015

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
Copy link
Member

eddyb commented Jun 1, 2015

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

@arielb1
Copy link
Contributor

arielb1 commented Jun 2, 2015

@dpc

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

@dpc
Copy link
Contributor Author

dpc commented Jun 2, 2015

@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
Copy link
Contributor

arielb1 commented Jun 2, 2015

Weird. Could you try and reduce that function?

@dpc
Copy link
Contributor Author

dpc commented Jun 3, 2015

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

@steveklabnik
Copy link
Member

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

@dpc
Copy link
Contributor Author

dpc commented Jun 11, 2015

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

@rprichard
Copy link
Contributor

@dpc I reduced your code and filed #26468.

@dpc
Copy link
Contributor Author

dpc commented Jun 22, 2015

@rprichard : You're awesome!

@dpc
Copy link
Contributor Author

dpc commented Jan 9, 2016

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

@dpc dpc reopened this Jan 9, 2016
@dpc
Copy link
Contributor Author

dpc commented Jan 9, 2016

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

@dpc dpc closed this as completed Jan 9, 2016
@dpc dpc reopened this Jan 9, 2016
@dpc
Copy link
Contributor Author

dpc commented Jan 9, 2016

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. :/

@steveklabnik steveklabnik added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Mar 11, 2016
@Mark-Simulacrum
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
Projects
None yet
Development

No branches or pull requests

6 participants