After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 509270 - Memory leak in CamelMultipart
Memory leak in CamelMultipart
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Mailer
unspecified
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2008-01-14 01:48 UTC by Philip Van Hoof
Modified: 2008-01-14 15:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Strange that this one was never detected before ... (429 bytes, patch)
2008-01-14 01:48 UTC, Philip Van Hoof
none Details | Review
Two small fixes (661 bytes, patch)
2008-01-14 02:10 UTC, Philip Van Hoof
accepted-commit_now Details | Review

Description Philip Van Hoof 2008-01-14 01:48:10 UTC
Will attach a patch
Comment 1 Philip Van Hoof 2008-01-14 01:48:51 UTC
Created attachment 102784 [details] [review]
Strange that this one was never detected before ...
Comment 2 Philip Van Hoof 2008-01-14 02:10:26 UTC
Created attachment 102785 [details] [review]
Two small fixes
Comment 3 Matthew Barnes 2008-01-14 15:01:41 UTC
Looks right.  Couple notes:

  1) The test for NULL is unnecessary since NULL is a valid GList.
     g_list_free() is designed to handle it.

  2) Minor simplification, unrelated to the memory-leak.  You could get rid of
     the unref_part() function and do this in the finalize function:

     g_list_foreach (multipart->parts, (GFunc) camel_object_unref, NULL);

Approving since your current patch correctly fixes the problem.  The stuff above is optional.
Comment 4 Philip Van Hoof 2008-01-14 15:17:48 UTC
Committed