Re: [gmime-devel] g_mime_header_list_clear leaving a list in limbo

[stedfast comcast net]

Hi Ludo,

(I'd normally use inline comments, but my computer died on me the second time in 6 months, so I'm having to use a lame webmail interface to reply to email)

The problem with the g_mime_header_list_clear() is that it isn't removing the linked-list nodes as it frees them. Oops. There should be a list_unlink() call on each header before it is free'd. Another option is that it should call list_init() after freeing all the nodes.

I'm not sure what is going wrong with g_mime_header_iter_remove() and because of my dead linux box, I can't easily run it in a debugger at the moment. I'll try to look into it as soon as I figure out why my machine won't boot and install a replacement component.

Good catch on the g_mime_header_list_prepend() using list_append(). I'll commit a fix for this as soon as I send out this email.

Jeff

---

From: "Ludo Brands" <ludo brands free fr>
To: gmime-devel-list gnome org
Sent: Thursday, November 22, 2012 8:30:56 AM
Subject: [gmime-devel] g_mime_header_list_clear leaving a list in limbo

Dear all,

I want to reorder the headers in a particular order. The easiest is to
extract all headers, order them, clear the headerlist with
g_mime_header_list_clear and append the headers again in the desired
order with g_mime_header_list_append. Problem is that I'm getting a
sigsegv when calling g_mime_header_list_append (the 4th or 5th line).
When appending to a headerlist created with g_mime_header_list_new there
is no problem and when I do a g_mime_header_iter_remove for the complete
list, there is no problem either.
Looking in the sources I see that there is a loop over next =
header->next; ... header = next; until header NULL. But afaiu this
leaves list->tailpred pointing to a released node.

Also when deleting all headers with  g_mime_header_iter_remove, iter is
not invalidated and while g_mime_header_iter_first returns false,
g_mime_header_iter_last returns true indicating that tailpred isn't
updated neither. g_mime_header_iter_get_name returns a random value
after g_mime_header_iter_last. This seems to indicate that my "deleting
all headers with  g_mime_header_iter_remove" workaround isn't that
reliable and crash prone at one point.

Unrelated but kinda surprising to find that g_mime_header_list_prepend
calls list_append instead of list_prepend. The hash table is updated to
point to the newly added header but it is last in the headerlist.

thanks, Ludo

_______________________________________________
gmime-devel-list mailing list
gmime-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/gmime-devel-list