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
as always,
nick
nick@grawk.net * http://www.fargus.net/nick
Developer - Systems Engineer - Mad System Guru - MOO Sales
he picks up scraps of information/he's adept at adaptation
because for strangers and arrangers/constant change is here to stay
Reply to: