Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1232158
Summary: | drpm valgrind tests fail (memcpy/memmove confusion) | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dan Horák <dhorak> | ||||
Component: | valgrind | Assignee: | Mark Wielaard <mjw> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 22 | CC: | bugs.michael, dan, dodji, jakub, jzeleny, mchalk, mjw, mjw, mprchlik, panemade, rdossant, tmlcoch | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | ppc64 | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | valgrind-3.10.1-13.fc21 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2015-07-19 01:55:37 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 1071880 | ||||||
Attachments: |
|
Description
Dan Horák
2015-06-16 07:52:34 UTC
but this might be a glibc bug actually ... from a chat with glibc maintainer <dhorak> siddhesh: hi, can't https://bugzilla.redhat.com/show_bug.cgi?id=1232158 be a ppc64 glibc (ld.so) bug actually? <siddhesh> dhorak: my reading of this is that ld.so calls memmove, which seems to be handled by the memcpy interceptor function in valgrind <siddhesh> memmove can take overlapping arguments <siddhesh> so I'd look at valgrind first Should this be moved to the valgrind component? Could you run with valgrind -v -v? That should show the function intercepts. as can be seen from http://ppc.koji.fedoraproject.org/koji/packageinfo?packageID=19521 - build in f23 succeeds, but f22 and f21 fails. Can't f23 valgrind contain additional ppc64 related fixes? Rafael, can you take a look on Mark's request? (In reply to Dan Horák from comment #4) > as can be seen from > http://ppc.koji.fedoraproject.org/koji/packageinfo?packageID=19521 - build > in f23 succeeds, but f22 and f21 fails. Can't f23 valgrind contain > additional ppc64 related fixes? OK, now I see. That is odd indeed. On f23 both ppc64 and ppc64le succeed, but on both f21 and f22 ppc64 fails while ppc64le succeeds. f21 is fairly old. But f22 and f23/master shouldn't have any differences that I believe can explain this. So it must be some interaction issue between glibc and valgrind on f21/f22 on ppc64 which was somehow fixed for f23/rawhide. And that didn't impact ppc64le. I don't have any theory yet what that could be. Maybe related, maybe not. The following change is in glibc 2.22: commit b269211467795c71ae0ceb0ce79f2fb6614f33c9 Author: Adhemerval Zanella <azanella.ibm.com> Date: Wed Jan 21 07:41:46 2015 -0500 powerpc: wordcopy/memmove cleanup for ppc64 This patch cleanup some multiarch code related to memmmove optimization. Initial IFUNC support added specialized wordcopy symbols which turned in local IFUNC calls used by memmove default implementation. This change by removing then and used the optimized memmove instead for supported chips. Which glibc version does f22/f23 have? glibc-2.21.90-16.fc23.ppc64 and glibc-2.21-5.fc22.ppc64p7 Created attachment 1045800 [details]
valgrind_v_v log
Attached is the log output of running valgrind -v -v for the package.
Thanks to siddish for the analysis. What we think is happening is that in glibc 2.20 powerpc enabled MEMCPY_OK_FOR_FORWARD_MEMMOVE (commit glibc-2.19-778-gd6f68bb) which makes memmove just call memcpy in some cases. Normally this would not be an issue. valgrind would already have intercepted memmove so the memmove -> memcpy call wouldn't be there. But... this is a memmove copy in ld.so, which valgrind doesn't intercept. Valgrind does intercept memcpy in ld.so however. So now we see a memmove that calls into memcpy and valgrind complains that memcpy has overlaps. This was "fixed" in the commit mentioned in comment #6 (commit glibc-2.21-50-gb269211) for glibc 2.22. Which renames the powerpc memmove to __ppc_memmove for internal calls. So now valgrind will not see/intercept that internal memcpy -> memmove call, and so won't do the overlap checking. If we are right then the fix for glibc 2.20 and 2.21 on powerpc64 is to also intercept memmove calls in ld.so and not just libc.so in valgrind (just like we already do for memcpy). (In reply to Mark Wielaard from comment #9) > Thanks to siddish for the analysis. Siddhesh of course. Sorry. If you credit someone, you should at least get their name right. My apologies. I think I know what the solution is, but I am unable to replicate. -bash-4.3$ valgrind ./drpm_test drpm_test_file_1.drpm drpm_test_file_2.drpm drpm_test_file_3.rpm drpm_test_file_4 drpm_test_file_5 ==5071== Memcheck, a memory error detector ==5071== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==5071== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==5071== Command: ./drpm_test drpm_test_file_1.drpm drpm_test_file_2.drpm drpm_test_file_3.rpm drpm_test_file_4 drpm_test_file_5 ==5071== [==========] Running 7 test(s). [ RUN ] test_drpm_read_err_mock [ OK ] test_drpm_read_err_mock [ RUN ] test_drpm_read_err_input [ OK ] test_drpm_read_err_input [ RUN ] test_drpm_read_ok [ OK ] test_drpm_read_ok [ RUN ] test_drpm_get_uint [ OK ] test_drpm_get_uint [ RUN ] test_drpm_get_string [ OK ] test_drpm_get_string [ RUN ] test_drpm_destroy_err [ OK ] test_drpm_destroy_err [ RUN ] test_drpm_destroy_ok [ OK ] test_drpm_destroy_ok [==========] 7 test(s) run. [ PASSED ] 7 test(s). ==5071== ==5071== HEAP SUMMARY: ==5071== in use at exit: 0 bytes in 0 blocks ==5071== total heap usage: 426 allocs, 426 frees, 16,321,313 bytes allocated ==5071== ==5071== All heap blocks were freed -- no leaks are possible ==5071== ==5071== For counts of detected and suppressed errors, rerun with: -v ==5071== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) My system has glibc-2.21-5.fc22.ppc64. Is glibc-2.21-5.fc22.ppc64p7 a special version? The patch that I assume will fix this is: diff --git a/shared/vg_replace_strmem.c b/shared/vg_replace_strmem.c index d4e5449..0f366bf 100644 --- a/shared/vg_replace_strmem.c +++ b/shared/vg_replace_strmem.c @@ -1141,6 +1141,10 @@ static inline void my_exit ( int x ) #if defined(VGO_linux) MEMMOVE(VG_Z_LIBC_SONAME, memmove) MEMMOVE(VG_Z_LIBC_SONAME, __GI_memmove) + /* See bug #349828 Override for ld64.so.1 like memcpy, because for some + arches MEMCPY_OK_FOR_FORWARD_MEMMOVE is set, which might cause memmove + to call memcpy. */ + MEMMOVE(VG_Z_LD64_SO_1, memmove) #elif defined(VGO_darwin) # if DARWIN_VERS <= DARWIN_10_6 But since I have been unable to replicate the original issue I am not 100% sure this is the correct approach. Turns out this only happens with the ppc64p7 glibc package variant, which only is installed on some newer powerpc hardware. With that it is easy to replicate (even /bin/ls will fail to run under valgrind). The proposed fix in comment #12 does indeed work. valgrind-3.10.1-13.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/valgrind-3.10.1-13.fc22 This problem occurs on f21 as well (http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2620726). Could this be fixed by a similar update for Fedora 21? valgrind-3.10.1-13.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/valgrind-3.10.1-13.fc21 (In reply to Matěj Chalk from comment #15) > This problem occurs on f21 as well > (http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2620726). > > Could this be fixed by a similar update for Fedora 21? Yes. Update submitted. Package valgrind-3.10.1-13.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing valgrind-3.10.1-13.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-11310/valgrind-3.10.1-13.fc22 then log in and leave karma (feedback). valgrind-3.10.1-13.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report. valgrind-3.10.1-13.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. |