Hello,
Did you actually try with rpctrace? It seems to be breaking it. For
instance:
#include <pthread.h>
#include <stdio.h>
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
void *f(void *foo)
{
pthread_mutex_lock(&mutex);
sleep(1);
pthread_mutex_unlock(&mutex);
return NULL;
}
int main(void) {
pthread_t t1, t2;
pthread_create(&t1, NULL, f, NULL);
pthread_create(&t2, NULL, f, NULL);
pthread_join(t1, NULL);
pthread_join(t2, NULL);
return 0;
}
When running this through rpctrace, rpctrace hangs, with the following
backtrace:
(gdb) bt
#0 0x010999ac in mach_msg_trap ()
at
/build/glibc-cU1xjk/glibc-2.24/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
#1 0x0109a146 in __mach_msg (msg=0x3003f10, option=1, send_size=64,
rcv_size=0, rcv_name=0, timeout=0, notify=0) at msg.c:110
#2 0x0804b812 in trace_and_forward (inp=0x3003f10, outp=0x3001f00)
at ../../utils/rpctrace.c:1357
#3 0x0105a23c in internal_demuxer (inp=<optimized out>,
outheadp=<optimized out>) at ../../libports/manage-one-thread.c:96
#4 0x0109a6fe in __mach_msg_server_timeout (demux=0x3005f8c, max_size=8192,
rcv_name=55, option=2048, timeout=0) at msgserver.c:108
#5 0x0105a2e5 in ports_manage_port_operations_one_thread (
demuxer=0x804b5c0 <trace_and_forward>, timeout=0)
at ../../libports/manage-one-thread.c:120
#6 0x0804a043 in trace_thread_function (arg=0x8059bc8)
at ../../utils/rpctrace.c:1382
#7 0x0106cd2f in entry_point (self=0x80562f8,
start_routine=0x804a030 <trace_thread_function>, arg=0x8059bc8)
at ./pthread/pt-create.c:64
AIUI, the problem is that rpctrace uses only one thread to do the
tracing, and since gsync_wait is blocking the RPC, the whole rpctrace
gets blocked. Unfortunately, that prevents from commiting such change,
since not being able to rpctrace a threaded program is really a concern.
Samuel
