Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: Stan Shebs <stan@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH/commit] Handle errors in tracepoint target agent
Date: Fri, 26 Mar 2010 14:44:00 -0000	[thread overview]
Message-ID: <201003261444.14280.pedro@codesourcery.com> (raw)
In-Reply-To: <4BACAD8F.3030909@codesourcery.com>

(could you please remember to put an empty line between
quotes and replies, so everyone else's eyes don't get
hurt?  Thanks in advance.  :-) )

On Friday 26 March 2010 12:50:23, Stan Shebs wrote:
> > But now, `error_desc' is leaking in the case you xmalloc it.
> >   
> It was leaking before. :-)  It needs to stick around indefinitely; it 
> guess it would work to free an old one just before allocating a new one.
> > When you fix that leak, you'll stumble of the fact that

I meant now, compared to before any patch was applied, of
course.  Word games are unfair!  :-)

> > while in others you have this:
> >
> >  ts->error_desc = (char *) xmalloc (p2 - p1 + 1);
> >   
> No, because the p2 != p1 test prior ensures we only allocate non-empty 
> strings.
> > How can you reliably know if you may xfree
> > ts->error_desc that way?  xfree ("") is a no go.
> > Comparing a pointer with "" is also not good.
> >   
> strlen.

My turn to triple yuck.  :-)

Would you object to this instead?

error_desc should only ever be accessed if the stopping reason
is tracepoint_error.

I've checked that all callers of parse_trace_status
currently only pass it the global status object.  If we
end up building an object of this type on the stack, we'll
need to memset it.  That would also be a requirement if we
checked for strlen instead..

-- 
Pedro Alves
2010-03-26  Pedro Alves  <pedro@codesourcery.com>

	gdb/
	* tracepoint.c (current_trace_status): Don't make sure error_desc
	is non-NULL here.
	(parse_trace_status): Release a previous error_desc string, and
	set it to NULL by default.  If stop reason is tracepoint_error, make
	sure error_desc is not left NULL.

---
 gdb/tracepoint.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

Index: src/gdb/tracepoint.c
===================================================================
--- src.orig/gdb/tracepoint.c	2010-03-26 14:32:01.000000000 +0000
+++ src/gdb/tracepoint.c	2010-03-26 14:38:31.000000000 +0000
@@ -202,9 +202,6 @@ char *stop_reason_names[] = {
 struct trace_status *
 current_trace_status ()
 {
-  /* Ensure this is never NULL.  */
-  if (!trace_status.error_desc)
-    trace_status.error_desc = "";
   return &trace_status;
 }
 
@@ -3157,7 +3154,8 @@ parse_trace_status (char *line, struct t
   ts->running_known = 1;
   ts->running = (*p++ == '1');
   ts->stop_reason = trace_stop_reason_unknown;
-  ts->error_desc = "";
+  xfree (ts->error_desc);
+  ts->error_desc = NULL;
   ts->traceframe_count = -1;
   ts->traceframes_created = -1;
   ts->buffer_free = -1;
@@ -3201,6 +3199,9 @@ Status line: '%s'\n"), p, line);
 	      end = hex2bin (p1, ts->error_desc, (p2 - p1) / 2);
 	      ts->error_desc[end] = '\0';
 	    }
+	  else
+	    ts->error_desc = xstrdup ("");
+
 	  p = unpack_varlen_hex (++p2, &val);
 	  ts->stopping_tracepoint = val;
 	  ts->stop_reason = tracepoint_error;


  reply	other threads:[~2010-03-26 14:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-26  1:56 Stan Shebs
2010-03-26 11:13 ` Pedro Alves
2010-03-26 12:40   ` Stan Shebs
2010-03-26 13:38     ` Pedro Alves
2010-03-26 14:17       ` Pedro Alves
2010-03-26 11:40 ` Pedro Alves
2010-03-26 12:50   ` Stan Shebs
2010-03-26 14:44     ` Pedro Alves [this message]
2010-03-26 15:20       ` Stan Shebs
2010-03-26 15:28         ` Eli Zaretskii
2010-03-26 15:53         ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201003261444.14280.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=stan@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox