Bug 521519

Summary: gedit 2.27 leaking memory
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: geditAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: rawhideCC: caolanm, dcantrell, idht4n, mclasen, rstrode
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-21 19:09:10 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 473303    
Description Flags
valgrind dump none

Description Adam Williamson 2009-09-06 12:56:54 EDT
After five days of uptime, my current Rawhide desktop, running a fairly average range of apps, was up well past 2.5GB in memory usage. I started closing things one by one to see what would happen.

When closing gedit, memory usage immediately dropped from over 2GB to under 800MB, suggesting a pretty large leak somewhere. I keep gedit open permanently, usually with three drafts of my Fedora Weekly News beat and several spec files and other miscellaneous files open. I close files and open different ones fairly frequently, but the FWN drafts tend to stay open permanently. None of the files I have open are particularly large. This wasn't a one-time occurrence; I've noticed the excessive memory usage over the last several long-time boots of the system, going back, oh, a month or so I'd say. Hadn't traced it back to gedit before this, though.

Version of gedit is gedit-2.27.5-1.fc12.x86_64 . Please advise me if there's any more information I can provide, or something I can do to help track down the leak; I'm not experienced in the procedures for this. Thanks!
Comment 1 David 2009-09-08 10:37:44 EDT
I ran valgrind on rawhide gedit and it found a hug number of errors:
==6352== Memcheck, a memory error detector
==6352== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==6352== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==6352== Command: /usr/bin/gedit
==6352== Invalid read of size 8
==6352==    at 0x950435: __strlen_sse2 (in /lib/libc-2.10.90.so)
==6352==    by 0xAD0AEB: g_get_filename_charsets (in /lib/libglib-2.0.so.0.2105.0)
==6352==    by 0xAD0CF1: ??? (in /lib/libglib-2.0.so.0.2105.0)
==6352==    by 0xB14029: g_thread_init_glib (in /lib/libglib-2.0.so.0.2105.0)
==6352==    by 0xD4E543: g_thread_init (in /lib/libgthread-2.0.so.0.2105.0)
==6352==    by 0x8066EA0: main (in /usr/bin/gedit)
==6352==  Address 0x44b1e20 is 8 bytes before a block of size 15 alloc'd
==6352==    at 0x400594C: malloc (vg_replace_malloc.c:195)
==6352==    by 0xAF1684: g_malloc (in /lib/libglib-2.0.so.0.2105.0)
==6352==    by 0xB0A369: g_strdup (in /lib/libglib-2.0.so.0.2105.0)
==6352==    by 0xB1B140: g_get_charset (in /lib/libglib-2.0.so.0.2105.0)
==6352==    by 0xAD0A8A: g_get_filename_charsets (in /lib/libglib-2.0.so.0.2105.0)
==6352==    by 0xAD0CF1: ??? (in /lib/libglib-2.0.so.0.2105.0)
==6352==    by 0xB14029: g_thread_init_glib (in /lib/libglib-2.0.so.0.2105.0)
==6352==    by 0xD4E543: g_thread_init (in /lib/libgthread-2.0.so.0.2105.0)
==6352==    by 0x8066EA0: main (in /usr/bin/gedit)
==6335== More than 1000 different errors detected.  I'm not reporting any more.
==6335== Final error counts will be inaccurate.  Go fix your program!
==6335== Rerun with --error-limit=no to disable this cutoff.  Note
==6335== that errors may occur in your program without prior warning from
==6335== Valgrind, because errors are no longer being displayed.
Comment 2 Caolan McNamara 2009-09-08 11:09:58 EDT
make sure you valgrind along the pattern of http://live.gnome.org/Valgrind
Comment 3 Adam Williamson 2009-09-08 12:51:53 EDT
Created attachment 360107 [details]
valgrind dump
Comment 4 Adam Williamson 2009-09-08 12:52:40 EDT
I ran as advised on the GNOME wiki page:

G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=20 /usr/bin/gedit &> dump

opened my usual beat pages, plus some spec files, closed the spec files and opened some different ones, left it running half an hour, again opened some different files, then quit. Dump is attached (comment #3).
Comment 5 Caolan McNamara 2009-09-08 15:25:37 EDT
gconftool-2 -g "/desktop/gnome/interface/accessibility"
say true ?
i.e. is accessibility enabled. Plenty of things are fairly leaky with accessibility enabled.
Comment 6 Adam Williamson 2009-09-09 00:24:13 EDT
It does, but I didn't specifically do anything to get into that state. So if that's the case, it means 'plenty of things are fairly leaky' in our current default configuration, apparently...

Fedora Bugzappers volunteer triage team
Comment 7 Adam Williamson 2009-09-09 00:28:34 EDT
...not to mention that this didn't happen until some time this Rawhide cycle. Certainly didn't happen in F11 state.

Fedora Bugzappers volunteer triage team
Comment 8 Jesse Keating 2009-10-21 17:54:50 EDT
adam, don't suppose you'd be willing to create a new user and use that user for a day or so and see if it also leaks?
Comment 9 Adam Williamson 2009-10-21 19:09:10 EDT
that would be pretty inconvenient :/. i haven't really seen this issue lately, though I haven't been explicitly looking. I'm going to close for now and re-open if I happen to reproduce in future.

Fedora Bugzappers volunteer triage team
Comment 10 Matthias Clasen 2009-10-21 19:26:43 EDT
It is worth noting that valgrind has been somewhat fixed in the meantime to not produce tons of meaningless warnings about strcmp and sse, so repeating that valgrind run might produce a much more readable dump. 

But when I've done so myself, I couldn't spot any major leaks in gedit.