After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 568558 - gedit doesn't release ram used to open a document
gedit doesn't release ram used to open a document
Status: RESOLVED OBSOLETE
Product: gedit
Classification: Applications
Component: file loading and saving
3.22.x
Other All
: Urgent critical
: ---
Assigned To: Gedit maintainers
Gedit maintainers
Depends on:
Blocks:
 
 
Reported: 2009-01-21 15:07 UTC by weltall2
Modified: 2020-11-24 09:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Valgrind logs opening a 7mb file two times (45.29 KB, text/plain)
2009-01-21 15:09 UTC, weltall2
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) (44.94 KB, text/plain)
2009-01-21 15:12 UTC, weltall2
Details

Description weltall2 2009-01-21 15:07:00 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.
Comment 1 weltall2 2009-01-21 15:09:40 UTC
Created attachment 126922 [details]
Valgrind logs opening  a 7mb file  two times
Comment 2 weltall2 2009-01-21 15:12:15 UTC
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)
Comment 3 Paolo Borelli 2009-08-24 20:43:49 UTC
can you see if this still happens with 2.27.X ? We do not mmap files anymore so things may have changed...
Comment 4 Ignacio Casal Quinteiro (nacho) 2009-10-24 00:47:04 UTC
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!
Comment 5 weltall2 2009-10-24 11:34:10 UTC
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)
Comment 6 Ignacio Casal Quinteiro (nacho) 2010-05-07 19:28:48 UTC
Any chance you can try with gedit 2.30? as we rewrote all the document loading code.
Comment 7 weltall2 2010-05-08 21:43:44 UTC
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.
Comment 8 Octavio Alvarez Piza 2011-02-25 20:53:51 UTC
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.
Comment 9 Patryk Zawadzki 2011-05-19 18:43:44 UTC
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?
Comment 10 mahfiaz 2012-01-04 14:01:12 UTC
This affects me on 3.2.3 as well.
Comment 11 Marco Leise 2013-11-12 04:48:18 UTC
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.
Comment 12 Eyal Allweil 2014-09-07 14:43:47 UTC
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.
Comment 13 palmelund 2016-11-30 20:31:48 UTC
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.
Comment 14 Nelson Benitez 2017-10-20 12:09:13 UTC
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.
Comment 15 Sébastien Wilmet 2020-11-24 09:58:55 UTC
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.