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 343683 - camel_multipart_get_part has wrong reference counting
camel_multipart_get_part has wrong reference counting
Status: RESOLVED OBSOLETE
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: 2006-06-02 11:19 UTC by Philip Van Hoof
Modified: 2018-12-11 06:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Philip Van Hoof 2006-06-02 11:19:20 UTC
It will not add a reference count, yet it's not declared as a const value. So people will probably unreference the instance. This would probably be incorrect, however. And can lead to rather strange debugging situations.

static CamelMimePart *
get_part (CamelMultipart *multipart, guint index)
{
        GList *part;

        if (!(multipart->parts))
                return NULL;

        part = g_list_nth (multipart->parts, index);
        if (part)
                return CAMEL_MIME_PART (part->data);
        else
                return NULL;
}

I'd say or make it a const, or add a reference.
Comment 1 Philip Van Hoof 2006-06-02 11:27:00 UTC
Adding the reference by yourself, and unreferencing afterwards gives you these warnings at the camel_object_unref:

camel-WARNING **: Trying to check junk data is OBJECT 'CamelObject'

camel-CRITICAL **: camel_object_cast: assertion `check_magic(o, ctype, CAMEL_OBJECT_MAGIC)' failed

camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed

camel-CRITICAL **: camel_object_ref: assertion `CAMEL_IS_OBJECT(o)' failed
Comment 2 Philip Van Hoof 2006-06-05 10:05:51 UTC
Interestingly this is not-so for camel_folder_get_message which returns a CamelMessage (which inherits the CamelMimePart). It looks like you do have to unreference the message instance coming from camel_folder_get_message.

Not sure if also destroying the parent folder of it will not destruct the message instance (the real used memory of it). It looks like CamelObject instance, however, still has a reference count of > 1 after it. But I have to check this using a unit test or something ...
Comment 3 Milan Crha 2018-12-11 06:34:57 UTC
Thanks for a bug report. I'm closing this, in favor of the development comment:

/**
 * camel_multipart_get_part:
 * @multipart: a #CamelMultipart object
 * @index: a zero-based index indicating the part to get
 *
 * Returns: (transfer none): the indicated subpart, or %NULL
 **/

Returning 'const' object would mean that the caller cannot modify it, which is not the intention of this function.

Why you saw the runtime warnings I do not know, but it's a long time, where many changes had been done in Camel, one of the biggest is the move to GObject.