Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1512887 - memory leak in when modprobe or rmmod zram [NEEDINFO]
Summary: memory leak in when modprobe or rmmod zram
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: gvfs
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ondrej Holy
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-14 12:02 UTC by likex
Modified: 2017-11-17 08:42 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-17 08:42:20 UTC
oholy: needinfo? (934249626)


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
GNOME Bugzilla 790427 None None None 2017-11-16 16:17:51 UTC

Description likex 2017-11-14 12:02:03 UTC
Description of problem:
gvfs-udisks2-volume-monitor eat many memory when modprobe or rmmod zram.


Version-Release number of selected component (if applicable):
gvfs-1.34.0-1.fc27.src.rpm

How reproducible:

#!/bin/sh
for((i=0;i<1000;i++))
{
modprobe zram num_devices=9
sleep 0.2
rmmod zram
}


Steps to Reproduce:
1.watch -n -0.1 "ps aux|grep udisk"
2.Execute the following script:
#!/bin/sh
for((i=0;i<1000;i++))
{
modprobe zram num_devices=9
sleep 0.2
rmmod zram
}

Actual results:
the memory of gvfs-udisks2-volume-monitor goes up.


Expected results:
the memory of gvfs-udisks2-volume-monitor will not change.

Comment 1 Ondrej Holy 2017-11-16 16:17:52 UTC
Thanks for your report.

I don't see any increase in ps output using your reproducer. Although I see some "definitely lost" entries in valgrind output, which are increasing using your reproducer, but I would say that this is not anything crucial - 17kb for your test case... what you mean with "many memory"?

Comment 2 Ondrej Holy 2017-11-17 08:42:20 UTC
I've proposed some upstream fixes, is there any change you can test them?


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