Here are the two killers, 300K is pretty bad, 71M is dangerous! CC'ing to the dbmail-dev list, as we should probably keep the deep debugging noise off the general list.
Thanks for these valgrind logs and the test script! Aaron ==1631== 303,136 bytes in 1,212 blocks are possibly lost in loss record 25 of 26 ==1631== at 0x40226DB: memalign (vg_replace_malloc.c:332) ==1631== by 0x4022735: posix_memalign (vg_replace_malloc.c:425) ==1631== by 0x415E0A3: (within /usr/lib/libglib-2.0.so.0.1200.12) ==1631== by 0x415EAC7: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1200.12) ==1631== by 0x4145725: g_list_prepend (in /usr/lib/libglib-2.0.so.0.1200.12) ==1631== by 0x41D6F4A: traverse_tree_keys (misc.c:1114) ==1631== by 0x4168E44: g_tree_foreach (in /usr/lib/libglib-2.0.so.0.1200.12) ==1631== by 0x41D6B04: g_tree_keys (misc.c:1127) ==1631== by 0x41C41AA: dbmail_mailbox_get_set (dbmail-mailbox.c:1332) ==1631== by 0x804EC61: _ic_fetch (imapcommands.c:1413) ==1631== by 0x804F1A3: _ic_uid (imapcommands.c:1792) ==1631== by 0x804D0DF: IMAPClientHandler (imap4.c:290) ==1631== ==1631== ==1631== 71,603,456 bytes in 288,752 blocks are still reachable in loss record 26 of 26 ==1631== at 0x40226DB: memalign (vg_replace_malloc.c:332) ==1631== by 0x4022735: posix_memalign (vg_replace_malloc.c:425) ==1631== by 0x415E0A3: (within /usr/lib/libglib-2.0.so.0.1200.12) ==1631== by 0x415EAA3: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1200.12) ==1631== by 0x413B018: g_hash_table_new_full (in /usr/lib/libglib-2.0.so.0.1200.12) ==1631== by 0x413B097: g_hash_table_new (in /usr/lib/libglib-2.0.so.0.1200.12) ==1631== by 0x4134AA5: g_quark_from_static_string (in /usr/lib/libglib-2.0.so.0.1200.12) ==1631== by 0x4103B8A: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.1200.12) ==1631== by 0x4103D61: g_type_init (in /usr/lib/libgobject-2.0.so.0.1200.12) ==1631== by 0x4073A94: g_mime_init (in /usr/lib/libgmime-2.0.so.2.2.8) ==1631== by 0x8052405: main (imapd.c:40) On Mon, 2007-05-14 at 19:27 +0200, Peter Rabbitson wrote: > Aaron Stone wrote: > > First let's look at some debug logs and see what's going on. Maybe the > > program is caught in a tight loop somewhere? If there's a particular > > IMAP command string that immediately triggers the problem, that'd be > > sort of the ideal situation, but not necessarily likely. > > > > Since we use Glib, these instructions for profiling GNOME applications > > apply to us as well: > > http://developer.gnome.org/doc/guides/optimisation/Massif.html > > > > Please ask any and all questions along the way, we're more than happy to > > bring you up to speed on how to debug! > > > > Aaron > > > > Hi Aaron > > I played around with the latest rc2 build and my problem is still there > (bug 584). I spent more time on it and did a fully logged run of > valgrind as described in the url you gave me. Problem is I do not know > what to do about the output I get. You can find a tar of all the > information I could scramble at: > http://rabbit.us/pool/misc/dbmail_bug584.tar.bz2 > > The file includes: > dbmail_test - the script that made this happen > dbmail.conf - my config file > netstat.log - a netstat snapshot showing active connections/pids > mem.log - a `ps aux` showing the fat process > dbmail.err - a level 5 trace of the entire process > the valgrind/massif output for all dbmail processes > > I understand that this is way too much information, but hopefully you > can just glance at it and tell me right away what I should do next. > Thanks for the help! > > Peter > _______________________________________________ > DBmail mailing list > [email protected] > https://mailman.fastxs.nl/mailman/listinfo/dbmail _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
