Leif Jackson wrote: > 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, > > If you run your tests with valgrind in memcheck mode using > --suppressions=dbmail.supp in the contrib directory I created a while > back. Use options > > valgrind --suppressions=contrib/dbmail.supp --tool=memcheck > --leak-check=full --show- > reachable=yes --trace-children=yes --log-file=/tmp/valtrace > the logfile directory can be any you choose it will make a file per pid > and log the leaks that arn't suppressed by the valgrind suppession file. > That should help us track this down futher. As arron said the options > that you specified may also be needed but the tool should be memcheck. > Thanks for helping track this down. >
Here it is: http://rabbit.us/pool/misc/dbmail_bug584_memcheck.tar.bz2 The tar contains the same information as the previous one. None of the options I used before work - I guess they are specific to massif. Let me know what to do next. Peter _______________________________________________ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
