Amittai Aviram <amittai.aviram@xxxxxxxx> writes: > As you can see, instruction 0x4090e5 has "callq 0"! > So the question is why GCC has generated this code. I think this will happen if you link with the static pthread library and your program uses pthread_cancel but not pthread_mutex_destroy. To work around the problem, add some kind of reference to pthread_mutex_destroy so that the linker will pull it in. If you are using GNU ld, try its -u (or --undefined) option; e.g. -Wl,-upthread_mutex_destroy. libgcc/gthr-posix.h typically uses pthread functions via weak references. For example, __gthrw_pthread_mutex_destroy is a weak reference to pthread_mutex_destroy. If pthread_mutex_destroy is linked in to the program, then __gthrw_pthread_mutex_destroy is just another name for it; otherwise, the address of __gthrw_pthread_mutex_destroy is NULL. I guess the idea is that single-threaded programs can use libgcc without linking with the pthread library. __gthread_mutex_destroy calls __gthread_active_p to check whether the pthread functions have been linked in. __gthread_active_p checks only one function: typically pthread_cancel. In your case, that function was indeed linked in, so __gthread_active_p returned true. __gthread_mutex_destroy then called __gthrw_pthread_mutex_destroy; however, pthread_mutex_destroy was not linked in, so the call crashed. This problem does not happen with the shared pthread library, because if you get pthread_cancel from there, you get all the other pthread functions as well. I don't know how the GCC maintainers could change libgcc/gthr-posix.h to prevent this problem. Adding more runtime checks for individual pthread functions will not fix it; rather, something should ensure that all the necessary functions get linked in.
