471634 2023-06-29 15:40:30 +0000 strtod() gives inaccurate values on Alpine Linux (musl-libc) under valgrind 2023-07-02 08:31:44 +0000 1 1 6 Developer tools valgrind general 3.21.0 Other Linux RESOLVED DUPLICATE 421262 NOR normal --- 0 nicklaus.little jseward pjfloyd 0 oldest_to_newest 2238787 0 159980 nicklaus.little 2023-06-29 15:40:30 +0000 Created attachment 159980 Test File SUMMARY When running under valgrind on Alpine Linux, strtod() gives inaccurate values. Test was performed on x86_64 architecture. (The same test on Ubuntu valgrind v3.19 yielded the correct values.) Each test prints out the original value passed in followed by a comma and then the result of converting the value to a string (using sprintf(..., "%.17g", ...)) and parsing it using strtod(). Examining the bits of the resulting values indicates that the last 10-11 bits of the mantissa are zero'd out compared to the expected values. My best guess is that this has something to do with how valgrind's dynamic recompiler and musl's implementation of strtod(). STEPS TO REPRODUCE 1. Compile Test File: `g++ -Wall -o ValgrindStrtodTest ValgrindStrtodTest.cxx` 2. Run without valgrind to observe correct results: `./ValgrindStrtodTest` 3. Run with valgrind to observe incorrect results: `valgrind ./ValgrindStrtodTest` OBSERVED RESULT ~ $ g++ -Wall -o ValgrindTest cal-ro/ValgrindTest.cxx ~ $ ./ValgrindTest 71596396.900554374, 71596396.900554374: GOOD 37033884.342276432, 37033884.342276432: GOOD 71596396.900543213, 71596396.900543213: GOOD 37033884.342269897, 37033884.342269897: GOOD 7.2506449597179708e+307, 7.2506449597179708e+307: GOOD 1.7428478780436407e+308, 1.7428478780436407e+308: GOOD ~ $ valgrind ./ValgrindTest ==108== Memcheck, a memory error detector ==108== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==108== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info ==108== Command: ./ValgrindTest ==108== 71596396.900554373, 71596396.900543212: BAD 37033884.342276431, 37033884.342269897: BAD 71596396.900543212, 71596396.900543212: GOOD 37033884.342269897, 37033884.342269897: GOOD 7.2506449597179707e+307, 7.2506449597178859e+307: BAD 1.7428478780436407e+308, 1.7428478780438379e+308: BAD ==108== ==108== HEAP SUMMARY: ==108== in use at exit: 0 bytes in 0 blocks ==108== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==108== ==108== All heap blocks were freed -- no leaks are possible ==108== ==108== For lists of detected and suppressed errors, rerun with: -s ==108== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ~ $ uname -a Linux cf8449d6eb32 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 Linux ~ $ cat /etc/os-release NAME="Alpine Linux" ID=alpine VERSION_ID=3.18.2 PRETTY_NAME="Alpine Linux v3.18" HOME_URL="https://alpinelinux.org/" BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues" EXPECTED RESULT The output when running with valgrind should match the output when running without valgrind: 71596396.900554374, 71596396.900554374: GOOD 37033884.342276432, 37033884.342276432: GOOD 71596396.900543213, 71596396.900543213: GOOD 37033884.342269897, 37033884.342269897: GOOD 7.2506449597179708e+307, 7.2506449597179708e+307: GOOD 1.7428478780436407e+308, 1.7428478780436407e+308: GOOD SOFTWARE/OS VERSIONS Linux: Alpine 3.18 image running on WSL ADDITIONAL INFORMATION Also performed the same test on WSL Ubuntu image. The expected results were observed. 2238855 1 pjfloyd 2023-06-30 03:12:35 +0000 Does Musl use long doubles? Valgrind only handles 64 bit doubles. 2239065 2 nicklaus.little 2023-06-30 16:41:59 +0000 After looking through musl's strtod implementation, yes, long double is used. That is probably the issue. 2239260 3 pjfloyd 2023-07-02 08:31:44 +0000 Marking this as a duplicate. *** This bug has been marked as a duplicate of bug 421262 *** 159980 2023-06-29 15:40:30 +0000 2023-06-29 15:40:30 +0000 Test File ValgrindStrtodTest.cxx text/x-c++src 647 nicklaus.little I2luY2x1ZGUgPGNtYXRoPg0KI2luY2x1ZGUgPGNzdGRpbz4NCiNpbmNsdWRlIDxjc3RkbGliPg0K DQppbnQgY2hlY2tJdChkb3VibGUgdmFsdWUpDQp7DQoJY2hhciBzWzY0XTsNCg0KCWlmIChzdGQ6 OnNwcmludGYocywgIiUuMTdnIiwgdmFsdWUpIDwgMikNCgkJcmV0dXJuIDI7DQoNCglkb3VibGUg bmV3VmFsdWUgPSBzdGQ6OnN0cnRvZChzLCBudWxscHRyKTsNCg0KCWlmIChuZXdWYWx1ZSAhPSBu ZXdWYWx1ZSB8fCBuZXdWYWx1ZSA9PSBIVUdFX1ZBTCB8fCBuZXdWYWx1ZSA9PSAtSFVHRV9WQUwp DQoJCXJldHVybiAyOw0KDQoJcHJpbnRmKCIlLjE3ZywgJS4xN2c6ICVzXG4iLCB2YWx1ZSwgbmV3 VmFsdWUsIHZhbHVlID09IG5ld1ZhbHVlID8gIkdPT0QiIDogIkJBRCIpOw0KCXJldHVybiB2YWx1 ZSA9PSBuZXdWYWx1ZSA/IDAgOiAxOw0KfQ0KDQppbnQgbWFpbigpDQp7DQoJcmV0dXJuIGNoZWNr SXQoNzE1OTYzOTYuOTAwNTU0Mzc0KSArIGNoZWNrSXQoMzcwMzM4ODQuMzQyMjc2NDMyKSArIGNo ZWNrSXQoNzE1OTYzOTYuOTAwNTQzMjEyKSArIGNoZWNrSXQoMzcwMzM4ODQuMzQyMjY5ODk3KSAr DQoJCWNoZWNrSXQoNy4yNTA2NDQ5NTk3MTc5NzA4ZSszMDcpICsgY2hlY2tJdCgxLjc0Mjg0Nzg3 ODA0MzY0MDdlKzMwOCk7DQp9DQo=