From: Aleksandar Ristovski <aristovski@qnx.com>
To: gdb-patches@sources.redhat.com
Subject: [patch] varobj.c c_describe_child
Date: Mon, 22 Mar 2010 19:42:00 -0000 [thread overview]
Message-ID: <ho8h62$4ic$1@dough.gmane.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 950 bytes --]
Hello,
When printing children of a variable created with a pointer
type, gdb generates a copy of value of target type for each
child. This quickly exhausts memory in certain cases.
In my case, customer has a struct with 1600+ fields and of
size approx 900K. Listing children of such struct via a
variable created with a pointer to it, crashes gdb (gdb
version 6.8) due to running out of memory. The patch fixes
this by removing intermediate value and freeing it.
Note that with latest gdb from HEAD it doesn't crash, I
believe due to recent changes in lazy allocating the values,
but it still seems wrong to keep all these intermediate
values generated by 'adjust_value_for_child_access' in
'all_values' list.
Thanks,
--
Aleksandar Ristovski
QNX Software Systems
ChangeLog:
2010-03-22 Aleksandar Ristovski <aristovski@qnx.com>
* varobj.c (c_describe_child): Do not keep temporary parent
value
while fetching child's value.
[-- Attachment #2: varobj-removetempvalue-20100322-ChangeLog.patch --]
[-- Type: text/plain, Size: 155 bytes --]
2010-03-22 Aleksandar Ristovski <aristovski@qnx.com>
* varobj.c (c_describe_child): Do not keep temporary parent value
while fetching child's value.
[-- Attachment #3: varobj-removetempvalue-20100322.patch --]
[-- Type: text/plain, Size: 933 bytes --]
Index: gdb/varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/varobj.c,v
retrieving revision 1.156
diff -u -p -r1.156 varobj.c
--- gdb/varobj.c 3 Mar 2010 18:32:44 -0000 1.156
+++ gdb/varobj.c 22 Mar 2010 19:15:34 -0000
@@ -2821,6 +2821,12 @@ c_describe_child (struct varobj *parent,
parent_expression = varobj_get_path_expr (parent);
}
adjust_value_for_child_access (&value, &type, &was_ptr);
+ if (value != parent->value)
+ {
+ /* If value was created merely to later create child,
+ * do not keep it in value history. */
+ release_value (value);
+ }
switch (TYPE_CODE (type))
{
@@ -2902,6 +2908,9 @@ c_describe_child (struct varobj *parent,
*cfull_expression = xstrdup ("???");
/* Don't set value and type, we don't know then. */
}
+
+ if (value != parent->value)
+ value_free (value);
}
static char *
next reply other threads:[~2010-03-22 19:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-22 19:42 Aleksandar Ristovski [this message]
2010-03-25 18:29 ` Tom Tromey
2010-03-25 19:20 ` Aleksandar Ristovski
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='ho8h62$4ic$1@dough.gmane.org' \
--to=aristovski@qnx.com \
--cc=gdb-patches@sources.redhat.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