rpc debugging

rpc debugging

Post by steph » Wed, 23 Apr 1997 04:00:00



i'm debugging some simple rpcgen created rpc stuff and would
value any advice on how to go about debugging rpc applications
from those who've been there already.  i'll give you some
idea of my problem;

my server function

x_y_1_svc(bp_x_arg *x, struct svc_req *unused)
{
        static bp_x_arg res;

        /* set values in res */
        return res;

Quote:}

looks ok from the server side.  the values make sence
etc.  but when called from the client side of the rpc
via

        res = xproc_y_1(&arg, clnt);

res is 0 and i get the helpful message that
there was an `RPC: Remote system error'.  via
clnt_perror().

thanks for any suggestions.

stephen

 
 
 

rpc debugging

Post by Nigel Wa » Fri, 25 Apr 1997 04:00:00




Quote:>i'm debugging some simple rpcgen created rpc stuff and would
>value any advice on how to go about debugging rpc applications
>from those who've been there already.  i'll give you some
>idea of my problem;

>my server function

>x_y_1_svc(bp_x_arg *x, struct svc_req *unused)
>{
>    static bp_x_arg res;

>    /* set values in res */
>    return res;
>}

>looks ok from the server side.  the values make sence
>etc.  but when called from the client side of the rpc
>via

>    res = xproc_y_1(&arg, clnt);

>res is 0 and i get the helpful message that
>there was an `RPC: Remote system error'.  via
>clnt_perror().

>thanks for any suggestions.

>stephen

I think you are confusing the "old" and "new" style service routines.
Are you using the -N argument to rpcgen?  It looks like it.

In the "old" style service routines there is a single struct for input and
the results are a pointer to a structure, which the function return value.  
Hence the need to make this structure static.

In the "new" style, multiple input arguments are possible and the results  
are returned in a structure, a pointer to which is passed as an argument
to the service routine.

The service routine prototype you have given is of the "new" type,
but you are creating a static result structure and returning its pointer
as per the "old" type.  The new type service routines end in _svc and are
passed the "struct svc_req *" parameter.

From the prototype I would guess that the call has no input and returns
a single bp_x_arg structure? What you need to do is remove the static
declaration, and set the return values in x rather than res.  
Then return a value of TRUE (a bool_t value) which indicates that the
call is ok and a result should be returned to the caller.

    x_y_1_svc(bp_x_arg *x, struct svc_req *unused)
    {

            /* set values in x */
            x->? = something;

            return TRUE;
    }

--
-----------------------------------------------------------
Nigel Wade, System Administrator, Space Plasma Physics Group,
            University of Leicester, Leicester, LE1 7RH, UK

Phone :     +44 (0)116 2523568, Fax : +44 (0)116 2523555

 
 
 

1. prevent "oops" in RPC debugging code

Description:
  rpc_show_tasks is invoked when changing the RPC client debug mode.
  recent changes have allowed tk_msg.rpc_proc to be NULL, which caused
  rpc_show_tasks to "oops."  the following change fixes that, and
  provides a little extra clean up as well.

Apply Against:
  2.5.49

Test status:
  Compiles, links, boots.  Oops does not recur.

diff -Naur 07-counters/net/sunrpc/sched.c 08-debug-oops/net/sunrpc/sched.c
--- 07-counters/net/sunrpc/sched.c      Fri Nov 22 16:40:44 2002

                "-rpcwait -action- --exit--\n");
        alltask_for_each(t, le, &all_tasks)
                printk("%05d %04d %04x %06d %8p %6d %8p %08ld %8s %8p %8p\n",
-                       t->tk_pid, t->tk_msg.rpc_proc->p_proc,
+                       t->tk_pid,
+                       (t->tk_msg.rpc_proc ? t->tk_msg.rpc_proc->p_proc : -1),
                        t->tk_flags, t->tk_status,
                        t->tk_client, t->tk_client->cl_prog,
                        t->tk_rqstp, t->tk_timeout,
-                       t->tk_rpcwait ? rpc_qname(t->tk_rpcwait) : " <NULL> ",
+                       rpc_qname(t->tk_rpcwait),
                        t->tk_action, t->tk_exit);
        spin_unlock(&rpc_sched_lock);
 }

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. GNU termutils (tput and tabs) 2.0 are available

3. How to use rpc.portmap, rpc.mountd, rpc.nfsd?

4. proxy server

5. Where are rpc.portmap, rpc.mountd, rpc.nfsd?

6. sshd exec error

7. Dangers of rpc.portmap, rpc.mountd, rpc.nfsd

8. smarthost and bounces

9. RPC 4.0 vs RPC 4.1 vs TI RPC

10. Comparison bet soap rpc, dce rpc and sun rpc

11. Debugging RPC server programs

12. Debugging RPC from the shell

13. slab.c ATOMIC debug check to immediately trap atomic abuse while debugging