search for: pthread_getspecific

...us 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 returning NULL with an EINVAL error (POSIX recommends, but can't mandate, that course of action for technical reasons). In any case, the error message is lost, and any subseque...

...us 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 which returns EINVAL because glibc is able to detect invalid use of a pthread_key_t after it has been destroyed. In any case, the error message is lost, and any subsequent call...

..._create(pthread_key_t *key, void (*destr_function)(void*)) +{ + *key = malloc(sizeof(**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...

...`_start': (.text+0x18): undefined reference to `main' Xapian.o: In function `boot_Search__Xapian': /home/henry/projects/xapian/search-xapian/Xapian.c:8796: undefined reference to `Perl_Gthr_key_ptr' /home/henry/projects/xapian/search-xapian/Xapian.c:8796: undefined reference to `pthread_getspecific' .... Now, "undefined reference to `main'" usually indicates a missing main() function during linking, so it looks like something wonky is going on. Resolving this in a small project would be relatively easy, but Xapian is no small project :) Any ideas? Regards Henry /s...

...d. > > Signed-off-by: Eric Blake <eblake@redhat.com> > --- > src/threadlocal.c | 17 +++++++++++++---- > 1 file changed, 13 insertions(+), 4 deletions(-) > > @@ -104,8 +105,16 @@ threadlocal_set_name (const char *name) > { > struct threadlocal *threadlocal = pthread_getspecific (threadlocal_key); > > - if (threadlocal) > - threadlocal->name = name; > + /* Copy name, as the original may be residing in a module, but we > + * want our thread name to persist even after unload. */ > + if (threadlocal) { > + free (threadlocal->name); >...

...s 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 which returns EINVAL because > glibc is able to detect invalid use of a pthread_key_t after it has > been destroyed. In any case, the error message is lost, and...

...tls emulation _much_ cleaner. First, we need to put all tsan per-thread data into ThreadState object, accesses to ThreadState are already wrapped into cur_thread() function. So now we have a single function to modify, no macros spread across the codebase, no new files, etc. Then, I've looked at pthread_getspecific code in bionic and it is actually quite fast and does not call any other system function (except get_thread() which is basically an access to real tls). So we can use it, and then the whole support becomes merely: INLINE ThreadState *cur_thread() { #ifdef REAL_TLS return reinterpret_cast<Thre...

...us 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 which returns EINVAL because glibc is able to detect invalid use of a pthread_key_t after it has been destroyed. In any case, the error message is lost, and any subsequent call...

...us 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 which returns EINVAL because glibc is able to detect invalid use of a pthread_key_t after it has been destroyed. In any case, the error message is lost, and any subsequent call...

.....new code does not. nbdkit_error() might be nicer than perror() anyways. I'll let you decide what, if any, error reporting needs to be done beyond merely sending ENOMEM to the client. > +extern void * > +threadlocal_buffer (size_t size) > +{ > + struct threadlocal *threadlocal = pthread_getspecific (threadlocal_key); > + > + if (!threadlocal) > + abort (); > + > + if (threadlocal->buffer_size < size) { > + void *ptr; > + > + ptr = realloc (threadlocal->buffer, size); > + if (ptr == NULL) { > + nbdkit_error ("threadlocal_buffer: re...

...s 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 which returns EINVAL because > glibc is able to detect invalid use of a pthread_key_t after it has > been destroyed. In any case, the error message is lost, and...

...and printing functions for building your language's equivalent of 'printf'. - Helper functions for finding and running static constructors. - Getting and setting thread-local data in a way that uses the __thread attribute if available, and pthreads if not. (I notice that pthread_getspecific is extremely efficient on OS X.) - Low-level debugging support. One requirement is that all of these functions should be written in such as way as to not require the C++ runtime libraries, only C libs. These are the capabilities that the JVM provides languages implemented on > top of it, an...

...struct tls { size_t instance_num; /* Can be 0. */ struct sockaddr *addr; socklen_t addrlen; + int err; }; static pthread_key_t tls_key; @@ -150,3 +153,24 @@ tls_get_instance_num (void) return tls->instance_num; } + +void +tls_set_error (int err) +{ + struct tls *tls = pthread_getspecific (tls_key); + + if (tls) + tls->err = err; + else + errno = err; +} + +int +tls_get_error (void) +{ + int err = errno; + struct tls *tls = pthread_getspecific (tls_key); + + errno = err; + return tls ? tls->err : 0; +} -- 2.9.3

...found -- Looking for fenv.h -- Looking for fenv.h - found -- Looking for mach/mach.h -- Looking for mach/mach.h - not found -- Looking for mach-o/dyld.h -- Looking for mach-o/dyld.h - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Looking for pthread_getspecific in pthread -- Looking for pthread_getspecific in pthread - found -- Looking for pthread_rwlock_init in pthread -- Looking for pthread_rwlock_init in pthread - found -- Looking for pthread_mutex_lock in pthread -- Looking for pthread_mutex_lock in pthread - found -- Looking for dlopen in dl -- Looki...

On 2/11/20 11:15 AM, Richard W.M. Jones wrote: > Since commit 86fdb48c6a5362d66865493d9d2172166f99722e we have stored > the connection object in thread-local storage. > > In this very large, but mostly mechanical change we stop passing the > connection pointer around everywhere, and instead use the value stored > in thread-local storage. > > This assumes a 1-1 mapping

...- Looking for mach/mach.h > > -- Looking for mach/mach.h - not found > > -- Looking for mach-o/dyld.h > > -- Looking for mach-o/dyld.h - not found > > -- Looking for pthread_create in pthread > > -- Looking for pthread_create in pthread - found > > -- Looking for pthread_getspecific in pthread > > -- Looking for pthread_getspecific in pthread - found > > -- Looking for pthread_rwlock_init in pthread > > -- Looking for pthread_rwlock_init in pthread - found > > -- Looking for pthread_mutex_lock in pthread > > -- Looking for pthread_mutex_lock in pt...

...king for fenv.h - found > -- Looking for mach/mach.h > -- Looking for mach/mach.h - not found > -- Looking for mach-o/dyld.h > -- Looking for mach-o/dyld.h - not found > -- Looking for pthread_create in pthread > -- Looking for pthread_create in pthread - found > -- Looking for pthread_getspecific in pthread > -- Looking for pthread_getspecific in pthread - found > -- Looking for pthread_rwlock_init in pthread > -- Looking for pthread_rwlock_init in pthread - found > -- Looking for pthread_mutex_lock in pthread > -- Looking for pthread_mutex_lock in pthread - found > -- Loo...

On Tue, Aug 18, 2015 at 8:28 PM, Kostya Serebryany <kcc at google.com> wrote: > +dvyukov > > On Mon, Aug 17, 2015 at 8:37 AM, Renato Golin <renato.golin at linaro.org> > wrote: >> >> Folks, >> >> The review of patch http://reviews.llvm.org/D11532 is extremely slow >> due to the number of hacks, left-overs and general undesired changes >>

...IpnIst_or der_9D39DXpnNselect_result_pnSst_select_lex_unit_pn 0 0 -> _db_enter_ 340930 0 -> code_state 415816 0 -> my_thread_var_dbug 516399 0 -> pthread_getspecific 597094 0 <- pthread_getspecific 669144 0 <- my_thread_var_dbug . . <please ignore the 3rd column; I need to correct it> Basically, I would like to have a graphical display showing me the call flow between the various functi...

On Oct 25, 2011, at 6:09 AM, Marcello Maggioni wrote: > Hi, I'm trying to compile the latest clang/llvm SVN versions and I get > this error on multiple systems : Linking, not compiling, but still. I am getting a similar error when building this morning. > Undefined symbols for architecture x86_64: > "clang::Sema::checkPseudoObjectRValue(clang::Expr*)", referenced