| Summary: | valgrind reports "Conditional jump or move depends on uninitialised value" in memchr of macOS 10.12-10.15 | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | cquike |
| Component: | memcheck | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | c.maurer, phil.krylov, pjfloyd, sam |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | MacPorts | ||
| OS: | macOS | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | attachment-23588-0.html | ||
Maybe this is related to Bug 432801 where a compiler optimization leads to a comparison on (seemingly) undefined data. I just had a quick google and could only see a plain C implementation of memchr for XNU (nothing like _platform_memchr$VARIANT$Base). Would it be possible to show us the disassemble for _platform_memchr$VARIANT$Base ? Created attachment 143010 [details] attachment-23588-0.html I would love to work on it today but I hope you don't if I wait a few more days, still I do hope to have it fixed today pt., 29 paź 2021, 19:50 użytkownik Sam James <bugzilla_noreply@kde.org> napisał: > https://bugs.kde.org/show_bug.cgi?id=437790 > > Sam James <sam@gentoo.org> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| |sam@gentoo.org > > -- > You are receiving this mail because: > You are watching all bug changes. > > I don't have a 10.15 system to test this with, just an old macbook with 10.7.5 and a newer macbook with 12. Looking at the code, my guess is that in vg_replace_strmem.c the following block # if DARWIN_VERS >= DARWIN_10_10 MEMCHR(VG_Z_DYLD, memchr) /* _platform_memchr$VARIANT$Generic */ MEMCHR(libsystemZuplatformZddylib, _platform_memchr$VARIANT$Generic) /* _platform_memchr$VARIANT$Haswell */ MEMCHR(libsystemZuplatformZddylib, _platform_memchr$VARIANT$Haswell) # endif needs to be # if DARWIN_VERS >= DARWIN_10_10 MEMCHR(VG_Z_DYLD, memchr) /* _platform_memchr$VARIANT$Generic */ MEMCHR(libsystemZuplatformZddylib, _platform_memchr$VARIANT$Generic) /* _platform_memchr$VARIANT$Haswell */ MEMCHR(libsystemZuplatformZddylib, _platform_memchr$VARIANT$Haswell) # endif #if DARWIN_VERS >= DARWIN_10_14 /* not sure which version */ /* _platform_memchr$VARIANT$Base */ MEMCHR(libsystemZuplatformZddylib, _platform_memchr$VARIANT$Base) #endif For the moment I'm just guessing which version added this. I can't make this change to the sourceware git repo. The last macos version that is officially supported in 10.13. (In reply to Paul Floyd from comment #4) > I don't have a 10.15 system to test this with, just an old macbook with > 10.7.5 and a newer macbook with 12. > > Looking at the code, my guess is that in vg_replace_strmem.c the following > block > > # if DARWIN_VERS >= DARWIN_10_10 > MEMCHR(VG_Z_DYLD, memchr) > /* _platform_memchr$VARIANT$Generic */ > MEMCHR(libsystemZuplatformZddylib, _platform_memchr$VARIANT$Generic) > /* _platform_memchr$VARIANT$Haswell */ > MEMCHR(libsystemZuplatformZddylib, _platform_memchr$VARIANT$Haswell) > # endif > > needs to be > > # if DARWIN_VERS >= DARWIN_10_10 > MEMCHR(VG_Z_DYLD, memchr) > /* _platform_memchr$VARIANT$Generic */ > MEMCHR(libsystemZuplatformZddylib, _platform_memchr$VARIANT$Generic) > /* _platform_memchr$VARIANT$Haswell */ > MEMCHR(libsystemZuplatformZddylib, _platform_memchr$VARIANT$Haswell) > # endif > #if DARWIN_VERS >= DARWIN_10_14 /* not sure which version */ > /* _platform_memchr$VARIANT$Base */ > MEMCHR(libsystemZuplatformZddylib, _platform_memchr$VARIANT$Base) > #endif > > For the moment I'm just guessing which version added this. > > I can't make this change to the sourceware git repo. The last macos version > that is officially supported in 10.13. Hi, I have the same problem on 10.14 and 10.12. I tested your fix on 10.14 and 10.12, and it works! As 10.12 is affected, is there a chance we can get the fix merged in? Tested this on a 10.13 VM commit 39589df4d30e981022e6677051783892f2907998 (HEAD -> master, origin/master, origin/HEAD) Author: Paul Floyd <pjfloyd@wanadoo.fr> Date: Tue Nov 14 08:30:05 2023 +0100 Bug 437790 - valgrind reports "Conditional jump or move depends on uninitialised value" in memchr of macOS 10.12-10.15 Thanks! |
SUMMARY valgrind reports "Conditional jump or move depends on uninitialised value" in memchr of macOS 10.15 with a very simple program test: #include <stdio.h> #include <string.h> # cat test.c int main(int argc, char *argv[]) { char strval[100]; int len = sprintf(strval, "%.7G", 10.); if(memchr(strval, '.', len)) printf("IF len %d\n", len); else printf("ELSE len %d\n", len); } STEPS TO REPRODUCE 1. In a macOS 10.15: $ cc -o test test.c 2. valgrind test OBSERVED RESULT 3. Results: ==51455== Conditional jump or move depends on uninitialised value(s) ==51455== at 0x100617108: _platform_memchr$VARIANT$Base (in /usr/lib/system/libsystem_platform.dylib) ==51455== by 0x100003ECB: main (kk.c:11) EXPECTED RESULT According to POSIX (https://pubs.opengroup.org/onlinepubs/9699919799/functions/memchr.html) memchr should behave as it would read byte by byte until the character is found up to the len parameter. Since len is also the number of characters written by sprintf it shouldn't be the case that memchr reads uninitialised values SOFTWARE/OS VERSIONS macOS: 10.15 valgrind valgrind-3.17.0.GIT-lbmacos installed from macports.