bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 5/5] utils/rpctrace: fix output so that replies can be attrib


From: Samuel Thibault
Subject: Re: [PATCH 5/5] utils/rpctrace: fix output so that replies can be attributed to requests
Date: Sun, 15 Dec 2013 21:35:28 +0100
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)

Justus Winter, le Fri 13 Dec 2013 15:52:38 +0100, a écrit :
> Currently, it is impossible to properly attribute response messages to
> requests.  Even though rpctrace is single-threaded, its tracee may
> not.  Or there might be more than one tracee.  In any such case it is
> not guaranteed that the reply message we just processed is for the
> request we just printed.  Fix this by printing ellipsis with the port
> name, so that reply messages can be properly attributed:
> 
> task129(pid3312)->mach_port_allocate (3) ...134
> task129(pid3312)->mach_port_deallocate (pn{  1}) ...160
> 134... = 0 pn{ 30}
> 160... = 0

Ack.

> * utils/rpctrace.c (last_reply_port): New variable.
> (print_ellipsis): New function.
> (print_request_header): Optionally print ellipsis and update
> last_reply_port.
> (print_reply_header): Likewise.
> ---
>  utils/rpctrace.c |   28 ++++++++++++++++++++++++++--
>  1 file changed, 26 insertions(+), 2 deletions(-)
> 
> diff --git a/utils/rpctrace.c b/utils/rpctrace.c
> index f6e255b..9605089 100644
> --- a/utils/rpctrace.c
> +++ b/utils/rpctrace.c
> @@ -1,7 +1,7 @@
>  /* Trace RPCs sent to selected ports
>  
> -   Copyright (C) 1998, 1999, 2001, 2002, 2003, 2005, 2006, 2009, 2011
> -   Free Software Foundation, Inc.
> +   Copyright (C) 1998, 1999, 2001, 2002, 2003, 2005, 2006, 2009, 2011,
> +   2013 Free Software Foundation, Inc.
>  
>     This file is part of the GNU Hurd.
>  
> @@ -1486,10 +1486,27 @@ static const char *const msg_types[] =
>  };
>  #endif
>  
> +/* We keep track of the last reply port used in a request we print to
> +   ostream.  This way we can end incomplete requests with an ellipsis
> +   and the name of the reply port.  When the reply finally arrives, we
> +   start a new line with that port name and an ellipsis, making it
> +   easy to match it to the associated request.  */
> +static mach_port_t last_reply_port;
> +
> +/* Print an ellipsis if necessary.  */
> +static void
> +print_ellipsis (void)
> +{
> +  if (MACH_PORT_VALID (last_reply_port))
> +    fprintf (ostream, " ...%u\n", (unsigned int) last_reply_port);
> +}
> +
>  static void
>  print_request_header (struct sender_info *receiver, mach_msg_header_t *msg)
>  {
>    const char *msgname = msgid_name (msg->msgh_id);
> +  print_ellipsis ();
> +  last_reply_port = msg->msgh_local_port;
>  
>    if (TRACED_INFO (receiver)->name != 0)
>      fprintf (ostream, "%4s->", TRACED_INFO (receiver)->name);
> @@ -1507,6 +1524,13 @@ static void
>  print_reply_header (struct send_once_info *info, mig_reply_header_t *reply,
>                   struct req_info *req)
>  {
> +  if (last_reply_port != info->pi.pi.port_right)
> +    {
> +      print_ellipsis ();
> +      fprintf (ostream, "%u...", (unsigned int) info->pi.pi.port_right);
> +    }
> +  last_reply_port = MACH_PORT_NULL;
> +
>    /* We have printed a partial line for the request message,
>       and now we have the corresponding reply.  */
>    if (reply->Head.msgh_id == req->req_id + 100)
> -- 
> 1.7.10.4
> 
> 

-- 
Samuel
<m> argh, pi est plus grand que 2. Ca casse tout
 -+- #ens-mim -+-



reply via email to

[Prev in Thread] Current Thread [Next in Thread]