[gmime-devel] Re-4: Malformed name in from/to header results in hang

Hi Jeff,
I changed my code according to your suggestion, but it doesn't fix the hang :(
But maybe the application will now free the memory correctly.
My application is running in a kind of batch mode - it processes thousands of eml files in a folder, so if gmime_init() and gmime_shutdown are leaking than the process should hang after while - but this doesn't happen. It happen only with this eml file I've attached to last mail.
If it helps I can try to find more mails which force the gmime to hang.
Original Message     
   processed by David.fx 
Re: Re-2: [gmime-devel] Malformed name in from/to header results in hang (18-Jul-2011 13:16)
On 07/18/2011 03:40 AM, Bastian Pfennigschmidt wrote:
Hi Jeff,
thanks a lot for your fast reply and bugfix.

You're welcome!

I have applied your patch and it seems to be correct now.
And your changes are better than mine, because you use the native Windows function GetACP() instead of g_get_charset() which doesn't seem to work correct on Windows Server 2008. That was one of the problems I'm fighting with on Friday.
On my developer maschine with Windows XP my workaround works like expected but if I run it on a Windows Server 2008 maschine the g_get_charset() function does not return the correct charset I think - I could not verify this in deep, but after using GetACP() it works.

Good to hear.

Another weird thing is that if I call g_mime_parser_construct_message() twice for the same eml file (in different functions and everytime surrounded with g_mime_init() and g_mime_shutdown()) the second time the library hangs at the same iconv call.
But now the errno is E2BIG which is incorrect because all the buffers seem to be ok.

Hmmm. My shutdown() code might not be 100% correct, then. Perhaps it is not resetting some variables.

g_mime_shutdown() was designed for programs which wanted to load and unload libgmime-2.so dynamically using dlopen() so that when they unloaded libgmime-2.so, they didn't leak a ton of memory.

This happen only if the gmime tries to convert from UTF-8 to UTF-8 - so I decided to change the order of the calls in g_mime_utils_decode_8bit() function - by adding the locale charset to the charsets array first.

  charsets[i++] = locale;
 if (!(included & USER_CHARSETS_INCLUDE_LATIN1))
  charsets[i++] = "iso-8859-1";
 if (!(included & USER_CHARSETS_INCLUDE_UTF8))
  charsets[i++] = "UTF-8";
The strange thing is, that this is not reproducable with any eml file - I've found only one which results in the hang. I have attached the file - so maybe you are able to find a better workaround for that.
Maybe this is a problem with my code - it not clear to me which memory I have to free or not.
Here is what I'm calling:

You need to call g_object_unref() on gfs, parser, and message once you are done using them (to prevent a leak). Otherwise, the code looks ok.

I'll take a look into shutdown() and see if I find anything obvious that would cause this problem, but it would probably be best for you to not repeatedly call g_mime_init() and g_mime_shutdown(). Instead, call g_mime_init() at program start and g_mime_shutdown() at program exit.

Hope that helps,


To: fejj gnome org
Cc: gmime-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]