So we've run into an interesting problem.
gaim can load plugins (.so files). Two of those plugins, ssl-gnutls.so
and gaim-otr.so, use libgcrypt.
They each call gcry_set_allocation_handler(). [You can see where this is
going.]
Of course, only the last one "wins", and both plugins are now using
the last one's allocation handlers.
But worse, at quitting time, if the plugin that "won" is unloaded first,
the global free_func and friends now point to addresses *no longer in
memory*. The other plugin still has its cleanup to do, and calls
functions in libgcrypt, causing a crash.
Any idea how one might work around this problem? I suppose linking
libgcrypt *staticly* into the plugin .so might work, at the expense of,
well, the static linking.
Thanks,
- Ian
_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
gaim can load plugins (.so files). Two of those plugins, ssl-gnutls.so
and gaim-otr.so, use libgcrypt.
They each call gcry_set_allocation_handler(). [You can see where this is
going.]
Of course, only the last one "wins", and both plugins are now using
the last one's allocation handlers.
But worse, at quitting time, if the plugin that "won" is unloaded first,
the global free_func and friends now point to addresses *no longer in
memory*. The other plugin still has its cleanup to do, and calls
functions in libgcrypt, causing a crash.
Any idea how one might work around this problem? I suppose linking
libgcrypt *staticly* into the plugin .so might work, at the expense of,
well, the static linking.
Thanks,
- Ian
_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel