🚀 go-pugleaf

In article <KANZE.95Oct23144453@slsv7xt.lts.sel.alcatel.de>, kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
|> In article <46ff06$1ss@ubszh.fh.zh.ubs.com> jis@ubszh.net.ch (Johnston
|> Ian (by ubsswop)) writes:

[snip]

|> |> Seriously, though, I do find that using a debugger is the only way to start
|> |> pinning down what is going on with complex system calls, across a client-
|> |> server link. If something goes wrong, sometimes you don't even know
|> |> whether it was the client or the server that had a problem.
|> 
|> Just curious, you *do* instrument your code, don't you?  And you do
|> have an external specification at the link level?  So wouldn't a
|> message trace at the link level show immediate which side had the
|> problem?

Example: I have an error in my IDL file whereby the size of some structure is
wrong, so deep in the RPC server stub (automatically generated by IDL)
a memory overwrite occurs: the RPC server stub throws an exception (which
is caught by the server stub) so the server never notices anything amiss.
The exception goes across to the client as an error code, where it is
rethrown, and the client catches the error, saying "error xyz". All I see
is that the client has a problem. (And my IDL files are automatically generated
by Perl scripts, so the original bug may be in a Perl script...)

Yes, I do instrument my code, and I do have an external specification. But
I can't instrument automatically-generated RPC stub code (well, I could, but
would be a big effort, and in practice, more effort than running the debugger
to find what went wrong).

|> And maybe I'm just being naive, but I would suppose that a client
|> server link used some sort of layered protocol, and that each layer
|> was tested separately, so when debugging layer n, I wouldn't have to
|> worry about layers 1..n-1.

"For performance reasons", various systems I have worked on have been
bare-to-the-metal RPC or OLE. There may therefore not be any layered
protocol.

Ian