From: Siddhesh Poyarekar <siddhesh@redhat.com>
To: gdb-patches@sourceware.org
Subject: [PATCH] Remove more instances of unsafe alloca
Date: Mon, 23 Jul 2012 12:41:00 -0000 [thread overview]
Message-ID: <20120723181116.00a4b508@spoyarek> (raw)
[-- Attachment #1: Type: text/plain, Size: 593 bytes --]
Hi,
I found another couple of instances of unsafe alloca usage in gdb, both
to do with trying to allocate memory on stack for a baseclass type. The
fix is on the lines of what was done in the following changeset:
http://sourceware.org/ml/gdb-cvs/2012-07/msg00044.html
I have verified that the fix does not cause any regressions on x86_64.
OK to commit?
Regards,
Siddhesh
gdb/ChangeLog:
2012-07-23 Siddhesh Poyarekar <siddhesh@redhat.com>
* p-valprint.c (pascal_object_print_value): Replace potentially
unsafe alloca with xmalloc/xfree.
* valops.c (search_struct_method): Likewise.
[-- Attachment #2: alloca-cleanup.patch --]
[-- Type: text/x-patch, Size: 1929 bytes --]
? alloca-cleanup.patch
Index: gdb/p-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/p-valprint.c,v
retrieving revision 1.100
diff -u -r1.100 p-valprint.c
--- gdb/p-valprint.c 18 May 2012 21:02:49 -0000 1.100
+++ gdb/p-valprint.c 23 Jul 2012 12:34:37 -0000
@@ -797,8 +797,11 @@
if (boffset < 0 || boffset >= TYPE_LENGTH (type))
{
- /* FIXME (alloc): not safe is baseclass is really really big. */
- gdb_byte *buf = alloca (TYPE_LENGTH (baseclass));
+ gdb_byte *buf;
+ struct cleanup *back_to;
+
+ buf = xmalloc (TYPE_LENGTH (baseclass));
+ back_to = make_cleanup (xfree, buf);
base_valaddr = buf;
if (target_read_memory (address + boffset, buf,
@@ -807,6 +810,7 @@
address = address + boffset;
thisoffset = 0;
boffset = 0;
+ do_cleanups (back_to);
}
else
base_valaddr = valaddr;
Index: gdb/valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.297
diff -u -r1.297 valops.c
--- gdb/valops.c 24 Jun 2012 07:28:10 -0000 1.297
+++ gdb/valops.c 23 Jul 2012 12:34:40 -0000
@@ -2281,8 +2281,13 @@
if (offset < 0 || offset >= TYPE_LENGTH (type))
{
- gdb_byte *tmp = alloca (TYPE_LENGTH (baseclass));
- CORE_ADDR address = value_address (*arg1p);
+ gdb_byte *tmp;
+ struct cleanup *back_to;
+ CORE_ADDR address;
+
+ tmp = xmalloc (TYPE_LENGTH (baseclass));
+ back_to = make_cleanup (xfree, tmp);
+ address = value_address (*arg1p);
if (target_read_memory (address + offset,
tmp, TYPE_LENGTH (baseclass)) != 0)
@@ -2293,6 +2298,7 @@
address + offset);
base_valaddr = value_contents_for_printing (base_val);
this_offset = 0;
+ do_cleanups (back_to);
}
else
{
next reply other threads:[~2012-07-23 12:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-23 12:41 Siddhesh Poyarekar [this message]
2012-07-23 14:07 ` Tom Tromey
2012-07-23 18:09 ` Siddhesh Poyarekar
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=20120723181116.00a4b508@spoyarek \
--to=siddhesh@redhat.com \
--cc=gdb-patches@sourceware.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