Bug 1466017 - valgrind reports errors for all applications linked with ld-2.25.so on ARM
valgrind reports errors for all applications linked with ld-2.25.so on ARM
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: valgrind (Show other bugs)
26
armv7hl Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Mark Wielaard
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: ARMTracker BaseRuntimeFTBFS
  Show dependency treegraph
 
Reported: 2017-06-28 13:36 EDT by Stephen Gallagher
Modified: 2017-07-14 00:18 EDT (History)
14 users (show)

See Also:
Fixed In Version: valgrind-3.13.0-4.fc26 valgrind-3.12.0-9.fc25 valgrind-3.11.0-27.fc24
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-07 19:04:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
scratch build log (409.43 KB, text/plain)
2017-06-28 13:36 EDT, Stephen Gallagher
no flags Details
ARM hardwire for ld.so index function (2.34 KB, patch)
2017-06-29 11:14 EDT, Mark Wielaard
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 381805 None None None 2017-06-29 14:01 EDT

  None (edit)
Description Stephen Gallagher 2017-06-28 13:36:03 EDT
Created attachment 1292683 [details]
scratch build log

Description of problem:
libseccomp fails to build on armvhl in the current F26 buildroot (and F26 module buildroot).

Version-Release number of selected component (if applicable):
libseccomp-2.3.2-1.fc26

How reproducible:
Every time

Steps to Reproduce:
1. `fedpkg clone libseccomp`
2. `fedpkg switch-branch f26`
3. `fedpkg srpm`
4. `koji build --scratch f26 --arch=armv7hl libseccomp-2.3.2-1.fc26.src.rpm`

Actual results:
Build fails in %check (see attachment for logs)

Expected results:
Build succeeds

Additional info:
Comment 1 Paul Moore 2017-06-28 14:09:22 EDT
The problem is with the valgrind tests.  The specfile appears to set a BuildRequires for valgrind on armv7hl so I don't believe the issue is a missing valgrind binary, this means it is likely a valgrind notice/error.

Considering we aren't seeing valgrind notifications on any other arch/ABI, and that every single libseccomp valgrind test is failing, I suspect there is some issue with valgrind or the armv7hl toolchain.

I've requested a armv7hl system from Stephen (reporter) to try and get further information.
Comment 2 Stephen Gallagher 2017-06-28 19:13:46 EDT
I'm moving this to glibc. I can verify that valgrind is failing on all armv7hl runs, apparently in ld-2.25.so:

==9495== Memcheck, a memory error detector
==9495== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9495== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==9495== Command: ./success
==9495== 
==9495== Conditional jump or move depends on uninitialised value(s)
==9495==    at 0x401CF84: index (in /usr/lib/ld-2.25.so)
==9495== 
==9495== Conditional jump or move depends on uninitialised value(s)
==9495==    at 0x401CF88: index (in /usr/lib/ld-2.25.so)
==9495== 
==9495== 
==9495== HEAP SUMMARY:
==9495==     in use at exit: 0 bytes in 0 blocks
==9495==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==9495== 
==9495== All heap blocks were freed -- no leaks are possible
==9495== 
==9495== For counts of detected and suppressed errors, rerun with: -v
==9495== Use --track-origins=yes to see where uninitialised values come from
==9495== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 2 from 1)


I can reproduce this with any executable on armv7hl; I tested it with the following program (compiled with gcc-7.1.1-3.fc26.armv7hl):

```
int main(int argc, char **argv)
{
    return 0;
}
```
Comment 3 Stephen Gallagher 2017-06-28 19:15:07 EDT
For the record, I used arm03-packager01.cloud.fedoraproject.org which should be available to anyone with a Fedora account in the 'packager' group. I installed Fedora 26 pre-release with the latest updates as of this writing. Feel free to use this system to verify the issue.
Comment 4 Florian Weimer 2017-06-29 02:29:15 EDT
(In reply to Stephen Gallagher from comment #2)
> ==9495== Conditional jump or move depends on uninitialised value(s)
> ==9495==    at 0x401CF84: index (in /usr/lib/ld-2.25.so)
> ==9495== 
> ==9495== Conditional jump or move depends on uninitialised value(s)
> ==9495==    at 0x401CF88: index (in /usr/lib/ld-2.25.so)

Would you please try again after installing glibc debugging information?  Thanks.
Comment 5 Florian Weimer 2017-06-29 02:31:31 EDT
Never mind, I see that debugging information is already installed, but valgrind does not appear to use it.
Comment 6 Florian Weimer 2017-06-29 02:41:32 EDT
The cause was an outdated glibc-debuginfo package.  The valgrind suppression file apparently needs debugging information on armhfp to perform proper suppressions.

Disabling them again shows what's going on:

==32711== Conditional jump or move depends on uninitialised value(s)
==32711==    at 0x401CF84: index (strchr.S:99)
==32711==    by 0x4009563: expand_dynamic_string_token (dl-load.c:371)
==32711==    by 0x4009563: _dl_map_object (dl-load.c:2146)
==32711==    by 0x4000DEB: map_doit (rtld.c:586)
==32711==    by 0x401B633: _dl_catch_error (dl-error-skeleton.c:198)
==32711==    by 0x4001F7B: do_preload (rtld.c:757)
==32711==    by 0x4001F7B: handle_ld_preload (rtld.c:855)
==32711==    by 0x400403F: dl_main (rtld.c:1609)
==32711==    by 0x401A497: _dl_sysdep_start (dl-sysdep.c:253)
==32711==    by 0x4001883: _dl_start_final (rtld.c:410)
==32711==    by 0x4001883: _dl_start (rtld.c:516)
==32711==    by 0x4000ACF: ??? (in /usr/lib/ld-2.25.so)
==32711==  Uninitialised value was created by a stack allocation
==32711==    at 0x4001EB8: handle_ld_preload (rtld.c:832)

index/strchr is doing a word load from a partially-written stack-allocated buffer, therefore accessing uninitialized data.  This is normal for an optimized string function.  The uninitialized data does not affect the function result.
Comment 7 Stephen Gallagher 2017-06-29 06:25:51 EDT
Please don't close this; if the specific issue I raised is wrong, something is still causing valgrind to fail when building libseccomp on armv7hl.

I'll move back to that component for the moment while I investigate.
Comment 8 Mark Wielaard 2017-06-29 06:44:31 EDT
Lets assume this is a valgrind bug. It might be a glibc issue too though (looks like the ld.so symbol table is missing on arm?). Will investigate.
Comment 9 Stephen Gallagher 2017-06-29 06:47:26 EDT
Reassigning to valgrind at Mark Wielaard's request.
Comment 10 Mark Wielaard 2017-06-29 10:57:22 EDT
For ld.so we need a "hardwire" to intercept string/mem functions. We don't have one for index on arm32. We do for almost every other architecture. That is probably why this only shows up on arm32.

This was probably introduced by one of the recent security fixes in glibc.

commit 6d0ba622891bed9d8394eef1935add53003b12e8
Author: Florian Weimer <fweimer@redhat.com>
Date:   Mon Jun 19 22:31:04 2017 +0200

    ld.so: Reject overly long LD_PRELOAD path elements

valgrind uses LD_PRELOAD to load memcheck. So this path is most likely triggered.

I'll add a index/strchr hardwire for arm32 to see if that resolves the issue.
Comment 11 Mark Wielaard 2017-06-29 11:14 EDT
Created attachment 1292902 [details]
ARM hardwire for ld.so index function

The attached valgrind patch seems to solve the issue. There already was some code for an arm32 ld.so index function replacement it just wasn't hardwired yet.
Comment 12 Fedora Update System 2017-06-29 16:10:47 EDT
valgrind-3.13.0-4.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4315a2f0cd
Comment 13 Fedora Update System 2017-06-30 16:25:20 EDT
valgrind-3.13.0-4.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-4315a2f0cd
Comment 14 Fedora Update System 2017-07-05 10:01:48 EDT
valgrind-3.12.0-9.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-ffd8b851cc
Comment 15 Fedora Update System 2017-07-05 10:34:25 EDT
valgrind-3.11.0-27.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-1320773bc5
Comment 16 Fedora Update System 2017-07-05 23:53:26 EDT
valgrind-3.12.0-9.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-ffd8b851cc
Comment 17 Fedora Update System 2017-07-05 23:53:49 EDT
valgrind-3.11.0-27.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-1320773bc5
Comment 18 Fedora Update System 2017-07-07 19:04:59 EDT
valgrind-3.13.0-4.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
Comment 19 Fedora Update System 2017-07-13 15:19:34 EDT
valgrind-3.12.0-9.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
Comment 20 Fedora Update System 2017-07-14 00:18:31 EDT
valgrind-3.11.0-27.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.