Bug 1291647 - valgrind --leak-check=full --trace-children=yes hangs forever
valgrind --leak-check=full --trace-children=yes hangs forever
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: valgrind (Show other bugs)
7.2
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Mark Wielaard
qe-baseos-tools
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-15 06:55 EST by Eva Mrakova
Modified: 2016-01-05 04:32 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-05 04:32:56 EST
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)

  None (edit)
Description Eva Mrakova 2015-12-15 06:55:08 EST
Description of problem:

$ valgrind --leak-check=full --trace-children=yes createrepo .
hangs forever

Version-Release number of selected component (if applicable):
valgrind-3.10.0-16.el7


How reproducible:
always

Steps to Reproduce:
1. $ mkdir repo
2. $ cd repo
3. <put at least 2 rpm packages into the repo directory via cp/wget/curl...>
4. $ valgrind --leak-check=full --trace-children=yes createrepo .
hangs forever

Actual results:
valgrind outputs initial messages (not the results) and then hangs 


Expected results:
valgrind outputs all messages including the results and exits


Additional info:

actual output:

$ valgrind --leak-check=full --trace-children=yes createrepo .
==10842== Memcheck, a memory error detector
==10842== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==10842== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==10842== Command: /usr/bin/createrepo .
==10842== 
==10842== Memcheck, a memory error detector
==10842== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==10842== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==10842== Command: /usr/share/createrepo/genpkgmetadata.py .
==10842== 
Spawning worker 0 with 5 pkgs
Worker 0: ==10845== Memcheck, a memory error detector
Worker 0: ==10845== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
Worker 0: ==10845== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
Worker 0: ==10845== Command: /usr/share/createrepo/worker.py --pkgoptions=_reldir=/mnt/testarea/test/tstsmall/. --pkgoptions=_collapse_libc_requires=True --pkgoptions=_cachedir=None --pkgoptions=_baseurl=None --globalopts=clog_limit=10 --globalopts=sumtype=sha256 --pkglist=/tmp/tmp9AYIcb/pkglist-0
Worker 0: ==10845==

<hangs>

-----------------

works OK when called with --leak-check=summary instead of --leak-check=full
Comment 2 Mark Wielaard 2015-12-15 07:35:04 EST
I can replicate this. It does indeed work as expected with --leak-check=summary. But with --leak-check=full all the children hang during shutdown while trying to print the leak records.

It can be worked around by using valgrind --log-file=valgrind.%p.log
which will put the valgrind log in a separate file (%p is replaced by the pid number of each child) instead of logging to stderr.
Comment 3 Mark Wielaard 2016-01-05 04:32:56 EST
I looked a bit more into this, but the issue really is that stderr is used both for communication of results between the processes and for valgrind status/error messages. So the processes just get confused when valgrind puts output on stderr.

I don't believe there is any "real" solution, except make sure valgrind isn't using stderr but use an explicit log file with --log-file=valgrind.%p.log as described in comment #2.

I am closing this bug for now since it has a working workaround. Please reopen if you need a different solution.

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