search for: pthread_exit

These two patches make appliance building thread-safe. The first adds a test which easily demonstrates the problem. The second fixes the issue. For more information see Ian McLeod's analysis of the bug here: https://bugzilla.redhat.com/show_bug.cgi?id=790528#c5 Rich.

..., my_id, count); //free(data); //if (!__sync_bool_compare_and_swap(&count, oldval, newval)) /* Do some "work" so threads can alternate on mutex lock */ //fflush(stdout); //usleep(1); } printf("inc_count(): thread %ld exit\n", my_id); pthread_exit(NULL); } void *watch_count(void *t) { long my_id = (long)t; printf("Starting watch_count(): thread %ld\n", my_id); /* Lock mutex and wait for signal. Note that the pthread_cond_wait routine will automatically and atomically unlock mutex while it waits. Also, note that i...

...onst char *err; + int iterations; + + for (iterations = 0; iterations < 1000; ++iterations) { + guestfs_set_hv (g, "test"); + p = guestfs_get_hv (g); + if (!p || STRNEQ (p, "test")) { + fprintf (stderr, "invalid return from guestfs_get_hv\n"); + pthread_exit ((void *)-1); + } + free (p); + + guestfs_push_error_handler (g, NULL, NULL); + guestfs_set_hv (g, "test"); + p = guestfs_get_hv (g); + guestfs_pop_error_handler (g); + if (!p || STRNEQ (p, "test")) { + fprintf (stderr, "invalid return from guestfs...

...hello sin: 0.00 $ lli hellosin.bc hello sin: 0.50 phello.c ======================== #include <pthread.h> #include <stdio.h> #define NUM_THREADS 4 void *PrintHello(void *threadid) { long tid; tid = (long)threadid; printf("Hello from %ld.\n", tid); pthread_exit(NULL); } int main (int argc, char *argv[]) { pthread_t threads[NUM_THREADS]; int ret; long t; for(t=0; t<NUM_THREADS; t++){ #ifdef DEBUG printf("creating thread %ld\n", t); #endif ret = pthread_create(&threads[t], NULL, PrintHello, (void *)t); if (ret...

...printf("failed to start %s\n", buf); goto end; } printf("%s started\n", buf); if (virDomainDestroy(dom) != 0) { printf("failed to destroy %s\n", buf); } printf("%s destroyed\n", buf); end: virDomainFree(dom); pthread_exit(NULL); } int main(int argc, char **argv) { virConnectPtr conn = virConnectOpen("vbox:///session"); int i; int count = virConnectNumOfDefinedDomains(conn); char **names = malloc(count * sizeof(char *)); virConnectListDefinedDomains(conn, names, count); virDoma...

...(data); > //if (!__sync_bool_compare_and_swap(&count, oldval, newval)) > > /* Do some "work" so threads can alternate on mutex lock */ > //fflush(stdout); > //usleep(1); > } > printf("inc_count(): thread %ld exit\n", my_id); > pthread_exit(NULL); > } > > void *watch_count(void *t) > { > long my_id = (long)t; > > printf("Starting watch_count(): thread %ld\n", my_id); > > /* > Lock mutex and wait for signal. Note that the pthread_cond_wait > routine will automatically and atomi...

...> > phello.c > ======================== > #include <pthread.h> > #include <stdio.h> > #define NUM_THREADS 4 > > void *PrintHello(void *threadid) > { > long tid; > tid = (long)threadid; > printf("Hello from %ld.\n", tid); > pthread_exit(NULL); > } > > int main (int argc, char *argv[]) > { > pthread_t threads[NUM_THREADS]; > int ret; > long t; > for(t=0; t<NUM_THREADS; t++){ > #ifdef DEBUG > printf("creating thread %ld\n", t); > #endif > ret = pthread_create(&...

...ntext (which in x86 is just 6 registers). >> Not quite. It's also necessary to execute all the pending POSIX >> pthread_cleanup_pop() actions. > > POSIX pthread_cleanup_pop() can only be called directly from C++/C. > C doesn't haven't exceptions. But it does have pthread_exit(). > So yet again, this is a C++ issue. No, it isn't: The effect of calling longjmp() or siglongjmp() is undefined if there have been any calls to pthread_cleanup_push() or pthread_cleanup_pop() made without the matching call since the jump buffer was filled. An...

On 8 June 2018 at 10:52, PGNet Dev <pgnet.dev at gmail.com> wrote: [...] > So, there's a problem for OpenSSH build with spec'ing LD=/usr/bin/ld ? in this particular case, apparently yes. not generally, though. [...] > What's *intended* re: openssh? Support for LD=ld or only =gcc, or undef'd ? Well the intent is you should be able to set CC and LD to whatever you

...trying to start up a decode thread : #include <FLAC/stream_decoder.h> .... FLAC__StreamDecoder *flac = NULL; flac = FLAC__stream_decoder_new(); if (flac == NULL) { printf("[DECODE] Unable to initalize flac object\n"); pthread_exit(NULL); } And, oddly enough, it's consistantly failling at the FLAC__stream_decoder_new(). Is there any way to determine exactly why it isn't able to start a new instance? Though the flac executable wasn't able to compile, the libs did manage to compile. Here's the co...

...======== > #include <pthread.h> > #include <stdio.h> > #define NUM_THREADS 4 > > void *PrintHello(void *threadid) > { > long tid; > tid = (long)threadid; > printf("Hello from %ld.\n", tid); > pthread_exit(NULL); > } > > int main (int argc, char *argv[]) > { > pthread_t threads[NUM_THREADS]; > int ret; > long t; > for(t=0; t<NUM_THREADS; t++){ > #ifdef DEBUG > printf("creating thread %ld\n", t); >...

On 8 June 2018 at 11:21, PGNet Dev <pgnet.dev at gmail.com> wrote: > fyi > > add'l -- and looks unrelated -- issue > /usr/include/pthread.h:251:12: note: previous declaration of ?pthread_join? was here > extern int pthread_join (pthread_t __th, void **__thread_return); What included pthread.h? That's explicitly not supported by sshd: $ grep THREAD

...lt;pthread.h> >> #include <stdio.h> >> #define NUM_THREADS 4 >> >> void *PrintHello(void *threadid) >> { >> long tid; >> tid = (long)threadid; >> printf("Hello from %ld.\n", tid); >> pthread_exit(NULL); >> } >> >> int main (int argc, char *argv[]) >> { >> pthread_t threads[NUM_THREADS]; >> int ret; >> long t; >> for(t=0; t<NUM_THREADS; t++){ >> #ifdef DEBUG >> printf("creati...

...is just 6 registers). >>> Not quite. It's also necessary to execute all the pending POSIX >>> pthread_cleanup_pop() actions. >> POSIX pthread_cleanup_pop() can only be called directly from C++/C. >> C doesn't haven't exceptions. > > But it does have pthread_exit(). > >> So yet again, this is a C++ issue. > > No, it isn't: > > The effect of calling longjmp() or siglongjmp() is undefined if there > have been any calls to pthread_cleanup_push() or pthread_cleanup_pop() > made without the matching call...

Timo Juhani Lindfors wrote: > Nick Lewycky<nicholas at mxc.ca> writes: >> The interpreter uses libffi to make external function calls. However, it >> needs to be detected at LLVM's compile time. If you're using the >> released packages, we disabled that because we were worried about users >> who don't have libffi installed. > > This seems to be

Nick Lewycky <nicholas at mxc.ca> writes: > The interpreter uses libffi to make external function calls. However, it > needs to be detected at LLVM's compile time. If you're using the > released packages, we disabled that because we were worried about users > who don't have libffi installed. This seems to be quite a common problem (I too hit it once, thought it

...ntext class, which seems to allow me to intercept the > report_fatal_error() calls by installing a custom handler that writes to a > custom stream and then calls abort() instead of the default exit(). >  Alternatively, it looks like I can just spawn a thread for the LLVM work > and call pthread_exit() instead of abort() in the error handler, which does > not require messing with the process signal handlers.  Is there any reason > to prefer one over the other (thread vs. signal)? > > This leaves the following issues: > > Why is the error handling stuff in LLVMContext tied to i...

Previous discussion here: https://www.redhat.com/archives/libguestfs/2015-June/thread.html#00048 v2: - Use a cleanup handler to release the lock. - Rebase to upstream. Note I have not fixed the problem(s) with error handling (patch 3).

...the CrashRecoveryContext class, which seems to allow me to intercept the report_fatal_error() calls by installing a custom handler that writes to a custom stream and then calls abort() instead of the default exit(). Alternatively, it looks like I can just spawn a thread for the LLVM work and call pthread_exit() instead of abort() in the error handler, which does not require messing with the process signal handlers. Is there any reason to prefer one over the other (thread vs. signal)? This leaves the following issues: 1. Why is the error handling stuff in LLVMContext tied to inline asm? The err...

This is very useful for debugging multithreaded programs. Rich.