Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Doug Evans <xdje42@gmail.com>
To: gdb-patches@sourceware.org, ludo@gnu.org
Subject: [PATCH] record_latest_value: Call release_value_or_incref instead of release_value
Date: Mon, 03 Mar 2014 06:00:00 -0000	[thread overview]
Message-ID: <m3zjl7u8ik.fsf@sspiff.org> (raw)

Hi.

While testing a fix for bug 16612 I was getting segvs and traced it to
the new history-append! Scheme function.

The underlying gdb value was getting prematurely freed when its
Scheme wrapper was garbage collected, but it was still in the value
history.

I think this is because its reference counting is wrong.
Upon return from record_latest_value, its reference count is still one.
However it was one upon entry.  It should be two, right?
One for the Scheme wrapper and one for the history entry.

(gdb) guile (define histnum (history-append! (make-value 42)))

This fix feels right but it could use another set of eyes.
I'm left wondering how much potential for future bugs there are
because other code is calling release_value when it should be calling
release_value_or_incref.
Often it doesn't matter because the value was just created and
after releasing the value there is only one reference.
However, ISTM this is quite fragile: I reviewed ludo's patch and I
didn't expect record_latest_value to get the reference counting wrong.

As a start, before making any more changes, I wonder if it would be
correct to add an assert to release_value to verify the value hasn't
already been released: If it has already been released chances are
the reference count will be wrong upon return.

Could be misunderstanding something of course.

Regression tested on amd64-linux.

2014-03-02  Doug Evans  <xdje42@gmail.com>

	* value.c (record_latest_value): Call release_value_or_incref
	instead of release_value.

diff --git a/gdb/value.c b/gdb/value.c
index 4e8d1fe..27043ee 100644
--- a/gdb/value.c
+++ b/gdb/value.c
@@ -1659,7 +1659,11 @@ record_latest_value (struct value *val)
      from.  This is a bit dubious, because then *&$1 does not just return $1
      but the current contents of that location.  c'est la vie...  */
   val->modifiable = 0;
-  release_value (val);
+
+  /* The value may have already been released, in which case we're adding a
+     new reference for its entry in the history.  That is why we call
+     release_value_or_incref here instead of release_value.  */
+  release_value_or_incref (val);
 
   /* Here we treat value_history_count as origin-zero
      and applying to the value being stored now.  */


             reply	other threads:[~2014-03-03  6:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-03  6:00 Doug Evans [this message]
2014-03-03  6:02 ` Doug Evans
2014-03-03  9:17 ` Ludovic Courtès
2014-03-03 13:23   ` Joel Brobecker
2014-03-03 15:50     ` Ludovic Courtès
2014-03-03 16:20     ` Doug Evans
2014-03-03 16:22   ` Doug Evans
2014-03-13 16:34     ` Doug Evans

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=m3zjl7u8ik.fsf@sspiff.org \
    --to=xdje42@gmail.com \
    --cc=gdb-patches@sourceware.org \
    --cc=ludo@gnu.org \
    /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