A basic c++ program that simply outputs the number 123.456 to stdout, will show 111.111 when run through valgrind (see valgrind_float_test.cpp for clear example). The issue happens on a 64bit system with these versions: sys-libs/glibc-2.20-r2 dev-util/valgrind-3.10.1 sys-devel/gcc-4.8.4 or sys-devel/gcc-4.9.0 Another system with identical versions of these packages but 32bit did NOT have the bug. The program was compiled with these options:-O0 -g3 -fpic -std=c++1y Compiling the C++ program with -O0 or -O3 didn't change anything. Reproducible: Always Steps to Reproduce: 1. Compile attached program "valgrind_float_test.cpp" using: g++ -x c++ -O0 -g3 -fpic -std=c++1y -c ./valgrind_float_test.cpp 2. Link using: g++ -lstdc++ -o "./valgrind_float_test.elf" ./valgrind_float_test.o 3. Execute program normally: ./valgrind_float_test.elf 4. Check the output corresponds to this: 0 4.7 9.4 14.1 18.8 23.5 28.2 32.9 37.6 42.3 47 51.7 56.4 61.1 65.8 70.5 75.2 79.9 84.6 89.3 94 98.7 5. Execute the program through valgrind using: valgrind -q ./valgrind_float_test.elf 6. Check the output corresponds to this (or to something different from above): 0 4.7 9.4 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 Actual Results: The output of the program when run through valgrind gives: 0 4.7 9.4 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 11.1111 Expected Results: The output of the program is expected to be this, with and without valgrind: 0 4.7 9.4 14.1 18.8 23.5 28.2 32.9 37.6 42.3 47 51.7 56.4 61.1 65.8 70.5 75.2 79.9 84.6 89.3 94 98.7
Created attachment 405326 [details] valgrind_float_test.cpp Simple C++ program that shows the bug in action.
Created attachment 405328 [details] emerge --info (on affected computer) Ouput from `emerge --info` on the computer where the bug is present.
Created attachment 405332 [details] emerge --info (on *unaffected* 32 bit computer) Output from `emerge --info` on the 32bit computer referred from the description. The bug is not present on that computer.
An even simpler test case program is this one: #include <iostream> int main(int argc, char* argv[]){ std::cout << 3.14159 << std::endl << 314.159 << std::endl; return 0; } ---------------- When run normally, this program outputs: 3.14159 314.159 When run through valgrind, it outputs: 3.14159 111.111
So is this a toolchain issue, or a valgrind issue? Who do I assign this bug to?
I can't decide myself given that I'm not sure where the problem comes from. I only witnessed problems when using valgrind and I only use it to diagnose my own programs.
Created attachment 405472 [details] emerge --info on a similar system I'm not able to reproduce this on a similar, so I'm not sure what's going on here. Here's what I'm getting: amd64-hardened-gdb ~ # valgrind -q ./valgrind_float_test.elf 0 4.7 9.4 14.1 18.8 23.5 28.2 32.9 37.6 42.3 47 51.7 56.4 61.1 65.8 70.5 75.2 79.9 84.6 89.3 94 98.7 valgrind is very fragile. There are difference between our systems but I'm reluctant to start guessing. The one big difference is that my system is hardened, but a hardened toolchains usually causes, not "fixes", issues like this
(In reply to Anthony Basile from comment #7) > > valgrind is very fragile. There are difference between our systems but I'm > reluctant to start guessing. The one big difference is that my system is > hardened, but a hardened toolchains usually causes, not "fixes", issues like > this I just noticed that you are using the hardened profile, but not a hardened kernel but something else. Can you explain how your system is different that a typical hardened system (whatever that might mean). Also can you give me your cpu flags `cat /proc/cpuinfo`
I wasn't aware the kernel had any influence in this matter. There sure are many difference here. I'll describe them and try to reduce the differences later. Firstly, this machine runs within VirtualBox. The additions (kernel modules) have been compiled from those shipped with the executable. The host runs windows 8.1. I'll try to run it natively, this will take a lot of time. Secondly, the kernel I use is gentoo-sources 3.14.14. I haven't updated or recompiled it in a while for no special reason. I'll try to update it to something stable and more recent. I'll start by removing vbox from the equation, but this may take a day or two, so let me know if you have different priorities in mind.
Created attachment 405476 [details] cpuinfo from affected system (running as vbox guest)
Created attachment 405478 [details] kernel .config (gentoo-sources 3.14.14)
valgrind works as expected when running with this system natively (without vbox). It is not practical to use this system without vbox, so I'd be interested to hear suggestions. Thanks!
(In reply to corto from comment #12) > valgrind works as expected when running with this system natively (without > vbox). > > It is not practical to use this system without vbox, so I'd be interested to > hear suggestions. > > Thanks! Sorry no ideas here and I can't reproduce. Can you push this upstream.
This is a corner case bug which I can't really fix. If you want, push it upstream. I'm closing this bug report as cantfix.
