I'm trying to debug a problem with a DCE RPC server, which uses exception handling implemented on top of pthread cancels and sigsetjmp()/siglongjmp(). This appears to cause problems with valgrind after the first client request: ==29326== valgrind's libpthread.so: KLUDGED call to: siglongjmp (cleanup handlers are ignored) After which the call stack is trashed and the server is catatonic. In attempting to find the bug I'm looking for, I'm wondering whether it is possible to disable valgrind's interposing pthread library. -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com |
|
From: Julian S. <js...@ac...> - 2003-04-16 07:54:27
|
No, you can't disable it. The only reason we ship our own is that V can't simulate some important things in the real pthread library. All in all it's a gain pain in various parts of the body for us to have our own pthreads library, and believe me, we wouldn't do so if we could run the real one. J On Wednesday 16 April 2003 8:32 am, Luke Howard wrote: > I'm trying to debug a problem with a DCE RPC server, which uses exception > handling implemented on top of pthread cancels and > sigsetjmp()/siglongjmp(). > > This appears to cause problems with valgrind after the first client > request: > > ==29326== valgrind's libpthread.so: KLUDGED call to: siglongjmp (cleanup > handlers are ignored) > > After which the call stack is trashed and the server is catatonic. In > attempting to find the bug I'm looking for, I'm wondering whether it > is possible to disable valgrind's interposing pthread library. > > -- Luke |
|
From: Julian S. <js...@ac...> - 2003-04-16 07:58:57
|
> All in all it's a gain pain in various parts of the body for us to
^
t
Duh.
J
|
>No, you can't disable it. The only reason we ship our own is that
>V can't simulate some important things in the real pthread library.
>All in all it's a gain pain in various parts of the body for us to
>have our own pthreads library, and believe me, we wouldn't do so if
>we could run the real one.
Understood. Do you have any suggestions about how I might debug this
RPC server which appears to be unvalgrindable?
Before receiving an RPC, the main thread has the following stack:
(gdb) bt
#0 0x40192fb2 in vgPlain_do_syscall () from /usr/local/lib/valgrind/valgrind.so
#1 0x4052a3d2 in recvmsg (fd=9, message=0x496e784c, flags=0) at libc_jacket.c:221
#2 0x45fbed05 in RPC_SOCKET_RECVMSG (sock=9, iovp=0x496e7974, iovlen=1, addrp=0x0, ccp=0x496e797c,
serrp=0x496e7970) at ../../../ncklib/include/comsoc_bsd.h:339
#3 0x45fbe791 in receive_packet (assoc=0x417993b8, fragbuf_p=0x496e7ba4, ovf_fragbuf_p=0x496e7ba0,
st=0x496e7b98) at cnrcvr.c:1281
#4 0x45fbcded in receive_dispatch (assoc=0x417993b8) at cnrcvr.c:508
#5 0x45fbc4c6 in rpc__cn_network_receiver (assoc=0x417993b8) at cnrcvr.c:274
#6 0x4053358c in thread_wrapper (info=0x4179950c) at vg_libpthread.c:671
#7 0x4016ce88 in do__apply_in_new_thread_bogusRA () at vg_scheduler.c:2152
After:
(gdb) bt
#0 vg_do_syscall2 (syscallno=1079222716, arg1=1077504048, arg2=0) at vg_mylibc.c:76
#1 0x00000004 in ?? ()
#2 0x4017f9e2 in vgPlain_main () at vg_main.c:1442
Setting a breakpoint on siglongjmp() crashes valgrind.
-- Luke
--
Luke Howard | PADL Software Pty Ltd | www.padl.com
|