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!
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==
make sure you valgrind along the pattern of http://live.gnome.org/Valgrind
Created attachment 360107 [details] valgrind dump
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).
does gconftool-2 -g "/desktop/gnome/interface/accessibility" say true ? i.e. is accessibility enabled. Plenty of things are fairly leaky with accessibility enabled.
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
...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
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?
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
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.