Re: interesting behavior from rpctrace
> In message <[🔎] 20010723011147.D42B0994AE@perdition.linnaean.org>it was written:
> >Please run rpctrace under gdb, set a breakpoint at __assert_fail,
> >and examine rpctrace's data structure when it hits. Show us
> >what *inp and *info look like when the assert fails.
> >
> >You could also insert some printfs in new_send_wrapper and
> >new_send_once_wrapper so the output indicates all the bookkeeping that went
> >on before the mismatch arises.
>
> Possibly my inexperience with gdb harms me trying to do this, as it behaves completly
> differently when I run gdb on it:
>
> fugue:~# gdb rpctrace
> (gdb) set args apt-get source clisp
> (gdb) break __assert_fail
> Breakpoint 1 at 0x8049014
> (gdb) run
> Starting program: /usr/bin/rpctrace apt-get source clisp
> (no debugging symbols found)...Breakpoint 1 at 0x8049014
> (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
> Breakpoint 1 at 0x1088f95
> (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
>
> At this point it sits there indefinitely... I ^C it and:
>
> Program received signal SIGINT, Interrupt.
> 0x1072501 in _hurd_intr_rpc_mach_msg () from /lib/libc.so.0.2
> (gdb) backtrace
> #0 0x1072501 in _hurd_intr_rpc_mach_msg () from /lib/libc.so.0.2
> #1 0x11b7d85 in proc_wait () from /lib/libhurduser.so.0.0
> #2 0x10fe1f1 in wait4 () from /lib/libc.so.0.2
> #3 0x10fdfcb in waitpid () from /lib/libc.so.0.2
> #4 0x804a8b0 in __assert_perror_fail ()
> #5 0x107eceb in __libc_start_main () from /lib/libc.so.0.2
D'oh! Wrong thread! Do "info threads" and/or "thread apply all bt".
Reply to: