GNOME Bugzilla – Bug 613653
g_atexit() causes crash when used in library code
Last modified: 2010-03-27 11:46:07 UTC
gmime-object.c:type_registry_init() calls g_atexit(). If gmime is used in dlopen()'d code then this exit function code might be called at program exit and not when the dlopen()'d code is unloaded. To quote from the GLib manual: "As can be seen from the above, for portability it's best to avoid calling g_atexit() (or atexit()) except in the main executable of a program." In my example I tried to use gmime in a Pidgin protocol plugin on Fedora 13/i686 (Linux). As soon as I add g_mime_init(0) to the code (and NOTHING else!) Pidgin starts to crash at exit :-( I checked source code of the gmime releases 2.2 & 2.5, and both are affected. I think the correct solution would be to call type_registry_shutdown() from g_mime_shutdown() and make a call to g_mime_shutdown() mandatory before exiting a program. [for programs this isn't strictly necessary, unless you are hunting for memory leaks, e.g. with valgrind]
Created attachment 156823 [details] [review] Replace g_atexit() call with call from g_mime_shutdown() I tested my proposal (see patch against 2.2.25 sources) and the crash is gone now.
Fixed in 2.4.x and 2.5.x, I'd really like to stop maintaining 2.2.x as it is so old. All recent distros are shipping 2.4.x already so it shouldn't be problematic to make the switch.
Thanks. I would really like to see it also in 2.2.x, because in my checks it is unfortunately still used in some distributions (Debian, Maemo4). Then I could introduce a package build requirement "gmime >= 2.2.26" to make sure that the correct version is present on that platform.
debian ships 2.4.x
I have to take into consideration all the platforms where pidgin-sipe is currently build for. Sorry :-/ Don't get me wrong: I would really like to use gmime, because it worked like a charm in the test code I had already written. I hope fixing this bug will help others out there.
just released 2.2.26 with this patch. This better be the last 2.2.x release I ever have to do :-\ The problem, as I see it, is if I keep releasing 2.2.x, then there is no motivation for people to get their butts in gear and switch to 2.4.x, which means I have to forever maintain 2.2.x (which I REALLY don't want to do, because 2.4.x cleans up the code a LOT and 2.5.x is even cleaner). If people don't switch to 2.4.x, then some distros continue to ship 2.2.x rather than 2.4.x, which in turn demotivates developers from targeting 2.4.x. It's a never-ending cycle that I want to break out of. I continually get bitten by this :( So PLEASE PLEASE PLEASE fix pidgin-sipe to use 2.4.x where it can and only use 2.2.26 as a crutch for older platforms.
Ahh those misunderstandings :-) I of course meant that I need to be able to rely on old platforms that the bug is fixed, hence gmime >= 2.2.26. At least on Fedora 2.2.x is deprecated (F12: gmime-2.4.x, F13-Alpha: gmime-2.5.x) and 2.2.x backward compatibility is provided by the "gmime22" package. I have the configure.ac changes ready for automatic gmime-2.6 -> gmime-2.4 -> gmime-2.0 fallback, i.e. the build would use whatever is considered the newest gmime on that platform. I just need to know the 2.2, 2.4 and 2.5 releases where this bug is going to be fixed. Thanks again for fixing this issue.
sure, gmime-2.2.26 (released) gmime-2.4.16 (need to review the other fixes to make sure they don't break anything, then I can release) gmime-2.5.2 (will release alongside 2.4.16 since they share the same set of changes) Note that 2.5.x is an unstable series (although the core API is unlikely to change much, if at all, by 2.6.0 since the only remaining bits in my TODO are dealing with gpg crypto and possibly exposing the GpgMe bits to the public like the Balsa guys have requested).
Thanks for the information. I have now committed a GMime-based implementation to the pidgin-sipe repository that will automatically replace the libpurple one when a GMime 2.6 or 2.4 release, with this bug fix included, is available: <http://repo.or.cz/w/siplcs.git/commitdiff/6e8b7d1fa8ae22cd803f1886ea562049ef68cb1e> Following your request it'll not use the GMime 2.0 API for now. You'll have to ask the Fedora maintainers why they saw the need to move from GMime 2.4 to 2.5 in Fedora 13-Alpha. There is no information about this in the update notice <http://koji.fedoraproject.org/koji/packageinfo?packageID=325>
awesome, thank you! (and yea, I know about that fedora thing - I think they'll be putting 2.4 back after the 3-way conversation we had with the Balsa guys)