[nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:]
>I've been putting bitblt through some tests, and I keep getting write
>errors. In many cases, it doesn't happen, but when I send a lot of
>messages one after the other, it appears. For example: in the line
>test, I write 56 bytes, followed by 22 bytes. After doing this around
>6 times, I get write errors, and they seem to be caused by msg_send().
>(In the above it's not clear, but I use write() for sending messages,
>not msg_send())
Of course, your server isn't advertising a type of 'c' any more, is he?
What error do you get back? Or do you get short write counts, but not
an actual -1 with strerror() set?
You can leave a dbg_enter() call in msg_err(), and catch whoever's
setting the error. Trace their stack back, and you'll know why
(hopefully). BTW, do you know how to trace user stacks from the kernel
debugger? All you do is a "tf" to see the user's registers (assuming
he's the current process). Then or in 0x80000000 to the current value
of EBP (user is at 2 GB in reality, and kernel sees it this way). Then
do a "dv <addr> 2". The first word is the next EBP up on the stack, the
second is the EIP from the call. Iterate, or'ing in 0x8000000 to each
EBP and dumping the stack. A poor man's stack backtrace! If you note them,
you can jump back into DOS, use debug32, and turn each recorded EIP into
a source line number.
You can do sort of the same thing to an arbitrary process, but it involves
looking up the right pview in his vas, finding the right page in the pset
under the pview, and finding the physical page(s) for the stack. Once
you know the physical page, you can contruct the appropriate physical
address from the EBP value, and do "dp <addr> 2" to see it.
Using current proc and virtual addresses is, of course, much easier. Or
wait until I have adb running. With adoptive process debugging and
breakpoints, life should get much easier.
Andy
Received on Wed Dec 1 15:33:12 1993
This archive was generated by hypermail 2.1.8 : Wed Sep 21 2005 - 21:01:53 PDT