Hi Neil,
Neil Jerram <n...@ossau.uklinux.net> writes:
> Neil Jerram <n...@ossau.uklinux.net> writes:
>
>> Neil Jerram <n...@ossau.uklinux.net> writes:
>>
>>> My nightly build of master, on a relatively slow old machine, is
>>> hanging, on most nights, in `make check'.
>>
>> FWIW, I realized that my backtraces are very similar to those reported
>> by Dale here:
>> http://www.mail-archive.com/bug-gu...@gnu.org/msg05066.html.
>
> I think I have a reliable workaround for this, attached below. My
> nightly build will now use this patch, and hopefully that'll mean that
> it reliably produces benchmark data again.
Great, thanks for tracking this down!
> The hang seems to be caused by one thread (A) running (gc) at the same
> time as another thread (B) is doing GC_malloc_atomic. The third thread
> in the backtrace is the signal delivery thread, and not involved.
[...]
> My libgc is Debian version 1:7.1-3, so possibly this is a known libgc
> issue that's already fixed upstream; I haven't tried to check that yet.
The Debian patches at
http://ftp.de.debian.org/debian/pool/main/libg/libgc/libgc_7.1-3.diff.gz
look harmless.
However, I cannot reproduce the problem with a stock 7.1 and a recent
CVS libgc on x86_64-linux-gnu.
Can you try running the attached program? It stays at 200% CPU on my
dual-core machine (i.e., does not hang.)
Thanks,
Ludo’.
#define GC_THREADS 1
#define GC_REDIRECT_TO_LOCAL 1
#include <gc/gc.h>
#include <pthread.h>
#include <stdlib.h>
void *a;
static void *
alloc_thread (void *data)
{
while (1)
a = GC_MALLOC_ATOMIC (123);
return NULL;
}
static void *
gc_thread (void *data)
{
while (1)
GC_gcollect ();
return NULL;
}
int
main (int argc, char *argv[])
{
pthread_t alloc, gc;
GC_INIT ();
pthread_create (&alloc, NULL, alloc_thread, NULL);
pthread_create (&gc, NULL, gc_thread, NULL);
while (1);
return EXIT_SUCCESS;
}
