Yes, it is reproducible with cthreads.
In fact, I encountered the bug while debugging a cthreads program.
(I knew I forgot to mention something...)

I just now also confirmed that it is reproducible with a minimal example
to make sure it wasn't something particular to that program.

When debugging a multithreaded program with gdb, breakpoints triggered in
separate threads results in a SIGTRAP as if it was a regular terminating
signal.  For instance, with the program:

#include <pthread.h>

void *
foo (void *arg)
{
  return NULL;
}

int
main (int argc, char *argv[])
{
  pthread_t t;

  pthread_create (&t, NULL, foo, NULL);
  pthread_join (t, NULL);
}

the bug can be like this:

(gdb) break main
Breakpoint 1 at 0x8048507: file /home/cfhammar/src/hurd-test/gdb-threads.c, line 14.
(gdb) break foo
Breakpoint 2 at 0x80484f7: file /home/cfhammar/src/hurd-test/gdb-threads.c, line 6.
(gdb) run
Starting program: /home/cfhammar/test/hurd-test/gdb-threads
[New Thread 423.5]

Breakpoint 1, main (argc=1, argv=0x15ffdc8)
    at /home/cfhammar/src/hurd-test/gdb-threads.c:14
14        pthread_create (&t, NULL, foo, NULL);
(gdb) continue
Continuing.
[New Thread 423.6]

Program received signal SIGTRAP, Trace/breakpoint trap.
0x01057d8c in mach_msg_trap ()
    at /home/buildd/build/chroot-unstable/home/buildd/byhand/eglibc-2.10.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
2       /home/buildd/build/chroot-unstable/home/buildd/byhand/eglibc-2.10.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S: No such file or directory.
        in /home/buildd/build/chroot-unstable/home/buildd/byhand/eglibc-2.10.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S
Current language:  auto
The current source language is "auto; currently asm".

There are no problems when all the breakpoints are in main().  I have
only tested with gdb 7.0.1-2 from Debian.