Bug 521519 - gedit 2.27 leaking memory
Summary: gedit 2.27 leaking memory
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: gedit
Version: rawhide
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: F12Blocker, F12FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2009-09-06 16:56 UTC by Adam Williamson
Modified: 2013-01-10 05:27 UTC (History)
5 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2009-10-21 23:09:10 UTC


Attachments (Terms of Use)
valgrind dump (1.72 MB, text/plain)
2009-09-08 16:51 UTC, Adam Williamson
no flags Details

Description Adam Williamson 2009-09-06 16:56:54 UTC
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 14:37:44 UTC
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== 
==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)
==6352== 
<snip>
==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.
==6335==

Comment 2 Caolan McNamara 2009-09-08 15:09:58 UTC
make sure you valgrind along the pattern of http://live.gnome.org/Valgrind

Comment 3 Adam Williamson 2009-09-08 16:51:53 UTC
Created attachment 360107 [details]
valgrind dump

Comment 4 Adam Williamson 2009-09-08 16:52:40 UTC
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 19:25:37 UTC
does
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 04:24:13 UTC
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
https://fedoraproject.org/wiki/BugZappers

Comment 7 Adam Williamson 2009-09-09 04:28:34 UTC
...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
https://fedoraproject.org/wiki/BugZappers

Comment 8 Jesse Keating 2009-10-21 21:54:50 UTC
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 23:09:10 UTC
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
https://fedoraproject.org/wiki/BugZappers

Comment 10 Matthias Clasen 2009-10-21 23:26:43 UTC
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.


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