search for: pthread_key_delet

When a highly multi-threaded program such as nbdcopy encounters an error, there is a race condition in the library which can cause an assertion failure and thus a core dump: (1) An error occurs on one of the threads. nbdcopy calls exit(3). (2) In lib/errors.c, the destructor calls pthread_key_delete. (3) Another thread which is still running also encounters an error, and inside libnbd the library calls set_error(). (4) The call to set_error() calls pthread_getspecific. This is undefined behavior per POSIX, since the key has already been destroyed in step (2), but glibc handles it by return...

...ulti-threaded program such as nbdcopy encounters an > error, there is a race condition in the library which can cause an > assertion failure and thus a core dump: > > (1) An error occurs on one of the threads. nbdcopy calls exit(3). > > (2) In lib/errors.c, the destructor calls pthread_key_delete. > > (3) Another thread which is still running also encounters an error, > and inside libnbd the library calls set_error(). > > (4) The call to set_error() calls pthread_getspecific which returns > NULL (since the key has already been destroyed in step (2)), and this > cause...

When a highly multi-threaded program such as nbdcopy encounters an error, there is a race condition in the library which can cause an assertion failure and thus a core dump: (1) An error occurs on one of the threads. nbdcopy calls exit(3). (2) In lib/errors.c, the destructor calls pthread_key_delete. (3) Another thread which is still running also encounters an error, and inside libnbd the library calls set_error(). (4) The call to set_error() calls pthread_getspecific which returns NULL (since the key has already been destroyed in step (2)), and this causes us to call pthread_setspecific wh...

When a highly multi-threaded program such as nbdcopy encounters an error, there is a race condition in the library which can cause an assertion failure and thus a core dump: (1) An error occurs on one of the threads. nbdcopy calls exit(3). (2) In lib/errors.c, the destructor calls pthread_key_delete. (3) Another thread which is still running also encounters an error, and inside libnbd the library calls set_error(). (4) The call to set_error() calls pthread_getspecific which returns NULL (since the key has already been destroyed in step (2)), and this causes us to call pthread_setspecific wh...

> Yes, it is the same error referring to 4.1.2. > > /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c+ > +/4.1.2/i386-redhat-linux/bits/gthr-default.h:114:1: error: weakref > declaration must have internal > linkage > __gthrw(pthread_key_delete) > > There are several such errors. Are you sure you are usin gcc44? Don't you need to run CC=gcc44 CXX=g++44 ../llvm/configure instead? -- Regards, Konstantin

This version simply removes the call to pthread_key_destroy. It fixes the problem and allows us to leave the asserts alone so we can still catch real errors. Of course this leaks pthread_key_t in the case where you dlclose() the library. glibc has a limit of 128 thread-specific keys (and the first 32 are somehow "fast" in a way I could quite follow), so that's a thing. Rich.

When a highly multi-threaded program such as nbdcopy encounters an error, there is a race condition in the library which can cause an assertion failure and thus a core dump: (1) An error occurs on one of the threads. nbdcopy calls exit(3). (2) In lib/errors.c, the destructor calls pthread_key_delete. (3) Another thread which is still running also encounters an error, and inside libnbd the library calls set_error(). (4) The call to set_error() calls pthread_getspecific which returns NULL (since the key has already been destroyed in step (2)), and this causes us to call pthread_setspecific wh...

...> > > >> Yes, it is the same error referring to 4.1.2. >> >> /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c+ >> +/4.1.2/i386-redhat-linux/bits/gthr-default.h:114:1: error: weakref >> declaration must have internal >> linkage >> __gthrw(pthread_key_delete) >> >> There are several such errors. > > Are you sure you are usin gcc44? Don't you need to run CC=gcc44 CXX=g+ > +44 ../llvm/configure instead? > > -- > Regards, > Konstantin > > >

...dev] Compiling llvm and Clang on Linux > Yes, it is the same error referring to 4.1.2. > > /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c+ > +/4.1.2/i386-redhat-linux/bits/gthr-default.h:114:1: error: weakref > declaration must have internal > linkage > __gthrw(pthread_key_delete) > > There are several such errors. Are you sure you are usin gcc44? Don't you need to run CC=gcc44 CXX=g+ +44 ../llvm/configure instead? -- Regards, Konstantin

On Tuesday, 27 June 2017 13:55:57 CEST Richard W.M. Jones wrote: > We permit the following constructs in libguestfs code: > > if (guestfs_some_call (g) == -1) { > fprintf (stderr, "failed: error is %s\n", guestfs_last_error (g)); > } > > and: > > guestfs_push_error_handler (g, NULL, NULL); > guestfs_some_call (g); >

...> > > >> Yes, it is the same error referring to 4.1.2. >> >> /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c+ >> +/4.1.2/i386-redhat-linux/bits/gthr-default.h:114:1: error: weakref >> declaration must have internal >> linkage >> __gthrw(pthread_key_delete) >> >> There are several such errors. > > Are you sure you are usin gcc44? Don't you need to run CC=gcc44 CXX=g+ > +44 ../llvm/configure instead? > > -- > Regards, > Konstantin > > >

...ulti-threaded program such as nbdcopy encounters an > error, there is a race condition in the library which can cause an > assertion failure and thus a core dump: > > (1) An error occurs on one of the threads. nbdcopy calls exit(3). > > (2) In lib/errors.c, the destructor calls pthread_key_delete. > > (3) Another thread which is still running also encounters an error, > and inside libnbd the library calls set_error(). > > (4) The call to set_error() calls pthread_getspecific which returns > NULL (since the key has already been destroyed in step (2)), and this > cause...

Hi, > I ran > ../llvm/configure CC=gcc44 CXX=g++44 > make > > and still got the same error (I checked and CC=gcc44 and CXX=g++44 now in > build/Makefile.config).. is it exactly the same error? The original error referred to gcc-4.1 header files. Does the new error still refer to gcc-4.1 header files, or is it now talking about gcc-4.4 header files? Ciao, Duncan.

...*key)); + (*key)->ptr = NULL; + return 0; +} +static inline int pthread_setspecific(pthread_key_t key, const void *pointer) +{ + key->ptr = (void*) pointer; + return 0; +} +static inline void *pthread_getspecific(pthread_key_t key) +{ + return key->ptr; +} +static inline int pthread_key_delete(pthread_key_t key) +{ + free(key); + return 0; +} + + + +typedef struct {} pthread_mutex_t; #define PTHREAD_MUTEX_INITIALIZER {} -#define PTHREAD_ONCE_INIT {} static inline int pthread_mutex_lock(pthread_mutex_t *mutex) { return 0; } static inline int pthread_mutex_unlock(pthread_mutex_t...

...in virErrorInitialize(). It calls virErrorInitialize() which uses the wrapper function virThreadLocalInit(&virLastErr, virLastErrFreeData);. virThreadLocalInit() calls pthread_create() with a destructor function (virLastErrFreeData()) which will be called on thread exits. Trouble here is that pthread_key_delete() is never called in libvirt, but next time the system runs through the key list and libvirt has been unloaded the system will jump to an already unloaded function (the pointer were virLastErrFreeData() was loaded formerly) and consequently crash the process. Fixing this will not be easy, but a s...

I'm getting cycles of repeated crashes which occur and then stop occurring. Looking at the dumps via gdb shows that something peculiar is happening that looks like memory corruption: Program terminated with signal 6, Aborted. #0 0x0000003686e30285 in raise () from /lib64/libc.so.6 (gdb) up #1 0x0000003686e31d30 in abort () from /lib64/libc.so.6 (gdb) up #2 0x0000003686e6971b in

...+ exit (EXIT_FAILURE); + } +} + +/* Unload the plugin. */ +static void +vddk_unload (void) +{ + if (init_called) { + DEBUG_CALL ("VixDiskLib_Exit", ""); + VixDiskLib_Exit (); + } + if (dl) + dlclose (dl); + free (config); + free (libdir); + free (password); + pthread_key_delete (error_suppression); +} + static void trim (char *str) { @@ -133,12 +164,37 @@ debug_function (const char *fs, va_list args) nbdkit_debug ("%s", str); } +/* If the thread-local error_suppression pointer is non-NULL (we don't + * care about the actual value) then we will supp...

...Yes, it is the same error referring to 4.1.2. >>> >>> /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c+ >>> +/4.1.2/i386-redhat-linux/bits/gthr-default.h:114:1: error: weakref >>> declaration must have internal >>> linkage >>> __gthrw(pthread_key_delete) >>> >>> There are several such errors. >> >> Are you sure you are usin gcc44? Don't you need to run CC=gcc44 CXX=g+ >> +44 ../llvm/configure instead? >> >> -- >> Regards, >> Konstantin >> >> >> > > > &gt...

Thanks for the information. I am running on a machine on which gcc44 is installed but whose default installation is 4.1.2. I ran ../llvm/configure CC=gcc44 CXX=g++44 make and still got the same error (I checked and CC=gcc44 and CXX=g++44 now in build/Makefile.config).. I tried also ../llvm/configure CC=gcc44 CXX=g++44 --include_dir=<gcc44 include dir> but it didn't help

...;struct error_data'. + * + * All the 'struct error_data' structures associated with one handle + * are linked together in a linked list, so that we are able to free + * them when the handle is closed. (The pthread_key* API doesn't give + * us any other way to do this, in particular pthread_key_delete + * doesn't call the destructor associated with the key). + */ + +static void default_error_cb (guestfs_h *g, void *data, const char *msg); + +/* Stack of old error handlers. */ +struct error_cb_stack { + struct error_cb_stack *next; + guestfs_error_handler_cb error_cb; + void *...