Bug 866994
Summary: | tgz-out causes memory leak in guestfsd | ||
---|---|---|---|
Product: | [Community] Virtualization Tools | Reporter: | Richard W.M. Jones <rjones> |
Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> |
Status: | NEW --- | QA Contact: | |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | unspecified | CC: | infernix |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 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: |
Description
Richard W.M. Jones
2012-10-16 13:54:09 UTC
I attempted to reproduce this using a Fedora 19 guest with an ext4 filesystem (note the reporter said this only affects ext3 filesystems). guestfish --ro \ -a /dev/vg_data/F19Rawhidex64 -m /dev/vg_f18rawhidex64/lv_root \ sh "ps aux" : \ tar-out / /dev/null : \ sh "ps aux" The guestfsd process grew only modestly (1292 -> 1332 KB). This is using 1.19.51, so there are various features of my test which are not comparable with what the reporter found. The command used was actually tgz-out, not tar-out. I tried the above reproducer with s/tar-out/tgz-out/ (still with 1.19) but could not reproduce it. Will try on 1.18. I couldn't reproduce this with ext3 filesystems using libguestfs 1.16.32. guestfsd size before and after: /tmp/ps1:root 144 0.0 0.2 97332 1264 ? S 16:23 0:00 guestfsd /tmp/ps2:root 144 0.0 0.2 97340 1300 ? S 16:23 0:00 guestfsd Next I will try 1.18. Here is my test program. ------------------------ #!/bin/sh - set -e img=rhel3x64.img fs=/dev/sda2 extra=-v guestfish --ro -a $img -m $fs $extra <<EOF sh "ps aux" | cat > /tmp/ps1 tgz-out / /dev/null sh "ps aux" | cat > /tmp/ps2 EOF grep guestfsd /tmp/ps1 /tmp/ps2 ------------------------ Could not reproduce on 1.18.9 on Fedora either. Possibilities include: - Debian package that the reporter is using it broken in a Debian-specific way. - The leak only occurs while the tar command is running. (The test script only checks memory usage before and after). Reporter is using libguestfs_1.18.8-1 from Debian sid: http://packages.debian.org/source/sid/libguestfs I notice that tar creates an error file as it goes along. If the tar command was spewing error messages then that might cause some kind of failure, particularly if tmp-on-tmpfs. I couldn't reproduce this on Debian Wheezy + libguestfs 1:1.18.1-1 using an ext4 guest. Now trying with ext3 guest. Nor on an ext3 guest. The only possibilities I can see are: - problem in the methodology of the test: the leak only occurs while tar is running - something about the reporter's guest's ext3 filesystem (eg. tar prints lot of warnings?) I have two entirely different ext3 filesystems on which I can reproduce this when using 512MB ram for the libguestfs VM. The only common factor is that they generate relatively large tgz files (27.5GB and 29.4GB). Have you tested with really large filesystems like that? Also, I run a 'debug sh "fsck.ext3 -fy $PARTITION 1>/dev/null 2>/devnull; echo $?"' in a separate libguestfs process and check its return code before I do the tgz backup, so it is a filesystem for which the fsck return code is less than 4. I'm afraid I still can't reproduce this on Fedora so I'm scrubbing it for 1.20. (I did not yet try a very large filesystem) However I will leave the bug open so we can look at it again in a future release. |