GNOME Bugzilla – Bug 568558
gedit doesn't release ram used to open a document
Last modified: 2020-11-24 09:58:55 UTC
Please describe the problem: It seems gedit doesn't release the memory used to open a file when closing it making it so use ridiculous space in ram for little files if you opened a big file and closed it. Strangely gnome system monitor reports a lower memory use under the processes tab, but reports the used ram in the resources tab and top actually gives the high amounts of used ram. When reopening a big file this ram gets reused so this isn't exactly a *leak* but an annoying behavior Steps to reproduce: To try this: 1- open gedit 2- open top 3- notice the ram use: 19393 weltall 20 0 38980 19m 10m S 0 0.7 0:00.79 gedit 4- get a big file to open (mysql dumps are the best to try. I've tried with a ~50 mb dump) 5- you will notice an higher ram use, for sure > 300mb to open a 50mb file is a bit excessive but this is still an optimization issue which goes beyond this bug report: 19393 weltall 20 0 342m 305m 12m S 2 10.1 3:02.14 gedit 6- close the tab which had the file 7- check again top no changes in ram use: 19393 weltall 20 0 342m 305m 12m S 0 10.1 3:02.85 gedit this is definitely a memory leak or a bad ram retaining for future use implementation 8- try to reopen the file, gedit will take the same time to parse the file, but the increase of ram use is more little: 19393 weltall 20 0 381m 345m 12m S 0 11.4 6:01.23 gedit 9- close the file again the ram use doesn't change again Actual results: Expected results: I'd expect the ram to be released and left for use by other applications Does this happen every time? yes Other information: other gnome applications have similar "leak" issues like nautilus which after some days takes more than 300mb like nothing and closing windows doesn't release ram so maybe the problem might reside in underlying libraries.
Created attachment 126922 [details] Valgrind logs opening a 7mb file two times
Created attachment 126923 [details] valgrind log by opening the same 7mb file only one time and then closing it (while the previous one was opening closing opening closing) as you can see from the two valgrind logs there isn't an actual leak so it's more an annoying behaviour (as the ram gets reused in case i open a file bigger or equal, but as what's there doesn't get reused in case of opening the same file it seems quite useless to hold in hostage such quantities of ram, and while managing gb of sql dumps this is quite annoying)
can you see if this still happens with 2.27.X ? We do not mmap files anymore so things may have changed...
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
i've tried it with gedit 2.28.0 the situation seems to be more fluctuating. i got up from 5% of ram used to 30% to open a specific file when closing it didn't release still ram, but as i tried making new blank files i got back to 21% of ram use, reopening the big file made it go up to 29%. so the ram situation is a bit better but still it's not cleaning all the data (and the file takes still time to parse)
Any chance you can try with gedit 2.30? as we rewrote all the document loading code.
problem still persists. opened gedit PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19758 weltall 20 0 332m 21m 14m S 0 0.5 0:00.61 gedit opened a 10mb sql dump file (by drag and drop) and closed it as soon as the first text appeared PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19758 weltall 20 0 336m 43m 14m S 1 1.1 0:04.51 gedit made a new document PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19758 weltall 20 0 354m 44m 15m S 1 1.1 0:04.67 gedit reopened the same 10mb file by drag and drop and left gedit working (it remained 100% cpu use for a while when it went back to 0% cpu use it was like this) PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19758 stefano 20 0 479m 177m 15m S 0 4.5 0:57.06 gedit closed the document PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19758 stefano 20 0 463m 177m 14m S 0 4.5 0:58.07 gedit opened a new one PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19758 stefano 20 0 481m 178m 15m S 1 4.5 0:58.31 gedit reopened again the 10mb document and left it till cpu use was zero PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19758 stefano 20 0 492m 179m 15m R 0 4.5 1:22.61 gedit opened another 8,5mb sql document and left it till the cpu use was zero PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19758 stefano 20 0 622m 258m 15m S 2 6.5 2:22.98 gedit closed and reopened again the 10mb one PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19758 stefano 20 0 623m 261m 15m S 1 6.6 3:15.70 gedit now it seems some sort of caching is in action buy still the ram use increases without ever decreasing.
Any news on this bug? It affects me. Right now gedit is using about 200 MB because of having closed large files. RAM was never freed. If you provide information about where should the code be modified to fix this. Maybe some of us could try making a patch.
I get the same behavior with 3.0.2, gedit eventually forces my whole system to swap-out. Could this be related to the autocomplete feature?
This affects me on 3.2.3 as well.
I have noticed high memory use as well. I'm on Gentoo using gedit 2.30.4. At the moment there are ten open files, 9 of them with highlighting. They are mostly bash scripts with the longest at ~2000 lines but most of them quite short. Memory use is at 206 MiB.
I can confirm this behavior on gedit 3.10.4, running on Xubuntu 14.04. I opened a 44 MB text file, then closed the tab, and I can see through top that the process retains the memory.
I can confirm that the bug is still present in gedit 3.22.0 on Fedora 25. Opening a 12 kb file followed by a 16.7 MB file causes a total memory use of 313,8 MiB. Closing the big file keeps the memory in use, and reopening the same file results in only a small increase in used memory. Opening larger files likewise uses more memory, and don't free any memory when closed, even when memory usage is above 1GB, with only the small file open.
I think it would be worth to investigate if this can be caused by bug 784611 , as Gedit could be opening two GtkTextBuffer for the same file, and freeing only one on exit.
Mass-closing of all gedit bugzilla tickets. Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing: 2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3 By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements. We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.