Aaron,

 Thanks for getting this into CVS, odd tho the md5 issue didn't seem to
leak anywhere else. But I am sure it would have. Any ideas for the
currently supressed build_args_array_ext leak, this is kinda a big issue
in my mind as it leaks anywhere from 16bytes to 1600bytes on each
connection and depending on the daemon...etc. Thoughts?

-leif

p.s. maybe dbmail.supp and the valgrind info should be added to SVN with
some "hacking" info?



On Wed, February 8, 2006 1:36 am, [EMAIL PROTECTED] wrote:
>

> The following issue has been RESOLVED.
> ======================================================================
> http://www.dbmail.org/mantis/view.php?id=297
> ======================================================================
> Reported By:                ljackson
> Assigned To:                aaron
> ======================================================================
> Project:                    DBMail
> Issue ID:                   297
> Category:                   General
> Reproducibility:            always
> Severity:                   major
> Priority:                   normal
> Status:                     resolved
> Resolution:                 fixed
> Fixed in Version:           SVN Trunk
> ======================================================================
> Date Submitted:             01-Feb-06 22:58 CET
> Last Modified:              08-Feb-06 07:36 CET
> ======================================================================
> Summary:                    memory leaks patch
> Description:
> I did some digging in the current svn trunk and discoverd a few memory
> leaks. I was able to create a patch for them, However there is one I have
> found that doesn't have an easy fix. That is build_args_array_ext
> function in imap session code. I wille attache to this report and valgrind
>  suppressions file to help in narrowing down the memory leaks or any
> other issues in dbmail, this supresses a whole bunch of mess from glib and
>  gmime.
>
> This is still includes the fix for authsql memleak as it doesn't appear
> that it got into svn trunk. I added a check before db_query that looks for
>  unfreeed result sets and frees them automaticaly to avoid this in the
> future.
> ======================================================================
>
>
> ----------------------------------------------------------------------
> ljackson - 07-Feb-06 19:18
> ----------------------------------------------------------------------
> Aarron or Paul have you guys had a chance to look at this? And maybe the
> dbmail.supp file will help you with your sieve code..etc. Oh there is a
> proccess in which you can debug/memcheck dbmail in your working directory
>  without re-compiling to static.
>
> when you finish building your working directory, run dbmail-<daemon> -n
> once and then exit it. you will find in .libs/lt-dbmail-<daemon> which
> then can be passed to gdb and or valgrind memcheck:
>
> e.g.
>
> valgrind --suppressions=dbmail.supp --tool=memcheck --leak-check=full
> --show-reachable=yes .libs/lt-dbmail-pop3d -n
>
>
> or if you want to accualy watch it in deamon mode set your dbmail.conf
> down to 2 children and run:
>
> valgrind --suppressions=dbmail.supp --tool=memcheck --leak-check=full
> --show-reachable=yes --trace-children=yes --log-file=/tmp/valtrace
> libs/lt-dbmail-pop3d
>
> this will make after a exit a file /tmp/valtrace.<masterpid> that will
> have the memory debugging in it.
>
> Thanks,
> Leif
>
>
> p.s. Paul any ideas on the x86_64 issue?
>
> ----------------------------------------------------------------------
> aaron - 07-Feb-06 19:32
> ----------------------------------------------------------------------
> I've been using the dbmail.supp file this week, and it's really useful.
> Thanks!
>
>
> I admit that I haven't looked at the patch at all until just now; it's
> fairly short, so I'll go over it this evening. Thanks again!
>
> ----------------------------------------------------------------------
> aaron - 08-Feb-06 07:36
> ----------------------------------------------------------------------
> Nice patch! Now in SVN.
>
>
> The makemd5-as-argument bug is really a class of memory leaks. I fixed
> makemd5 in two more places in authsql.c, and grepped to ensure it wasn't
> broken anywhere else (fortunately it wasn't).
>
> Issue History
> Date Modified   Username       Field                    Change
> ======================================================================
> 01-Feb-06 22:58 ljackson       New Issue
> 01-Feb-06 22:58 ljackson       File Added:
> dbmail-svn-2.1.3-1970-memleaks.patch
>
> 01-Feb-06 22:58 ljackson       File Added: dbmail.supp
> 07-Feb-06 19:18 ljackson       Note Added: 0000985
> 07-Feb-06 19:32 aaron          Note Added: 0000986
> 08-Feb-06 07:36 aaron          Status                   new => resolved
> 08-Feb-06 07:36 aaron          Fixed in Version          => SVN Trunk
> 08-Feb-06 07:36 aaron          Resolution               open => fixed
> 08-Feb-06 07:36 aaron          Assigned To               => aaron
> 08-Feb-06 07:36 aaron          Note Added: 0000987
> ======================================================================
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
>


Reply via email to