Thu 13 Feb 2014 02:11:45 PM UTC, comment #1:
Yes, I can concur that this is indeed what's happening, and that the patch I've posted fixes the issue.
FlashCode asked for more explanation, so here goes:
The CMakeLists.txt has a section in it that only adds “-lpthread” on OpenBSD platforms. For all other platforms, libpthread is not linked.
However, gnutls uses libpthread. The glibc developers were clever and set things up such that if you don't explicitly link against libpthread, and library code still uses the functions from it, you'll instead wind up using functions that all return 0. This is so that single-threaded programs aren't burdened with the overhead of mutexes and such, when they aren't needed.
So when weechat was loaded, it would also load gnutls. Gnutls would then make several calls to pthread_mutex_init. Since libpthread wasn't loaded, this function would be hitting the code inside libc, which would simply return 0. So the mutex would never be initialized and instead it would contain uninitialized junk from malloc(). This was fine, since all the other pthread functions that libc implements do the same – return 0 – so nothing bad happens since that data is never touched.
However, later in the weechat initialization, the python plugin is loaded. This plugin directly or indirectly links in the proper libpthread. This means that after this point, all function calls to pthread_mutex_lock and pthread_mutex_unlock are hitting the real pthread code, that actually works with the data and does a lot more than simply return 0. But because these mutexes were not initialized before with the zero-returning pthread_mutex_init, the lock and unlock functions are dealing with uninitialized random malloc() data. And so, in lots of cases, we crash, or abort().
My patch simply removes the “if OpenBSD” guard and links against libpthread always.
|