Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Marcin Kościelnicki" <koriakin@0x04.net>
To: gdb-patches@sourceware.org
Cc: "Marcin Kościelnicki" <koriakin@0x04.net>
Subject: [PATCH] gdb/record-full: Use xmalloc instead of alloca for large buffers.
Date: Mon, 02 Nov 2015 18:42:00 -0000	[thread overview]
Message-ID: <1446489704-3173-1-git-send-email-koriakin@0x04.net> (raw)

On the newly added s390 target, it's possible for a single instruction
to write practically unbounded amount of memory (eg. MVCLE).  This caused
a stack overflow when alloca was used.

gdb/ChangeLog:

	* record-full.c (record_full_exec_insn): Use xmalloc for large buffers.
---
 gdb/ChangeLog     |  4 ++++
 gdb/record-full.c | 11 ++++++++++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 38a42ea..f4c0f57 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,7 @@
+2015-11-02  Marcin Kościelnicki  <koriakin@0x04.net>
+
+	* record-full.c (record_full_exec_insn): Use xmalloc for large buffers.
+
 2015-10-30  Pedro Alves  <palves@redhat.com>
 
 	* breakpoint.c (breakpoint_in_range_p)
diff --git a/gdb/record-full.c b/gdb/record-full.c
index 595e357..04d64ba 100644
--- a/gdb/record-full.c
+++ b/gdb/record-full.c
@@ -65,6 +65,8 @@
 
 #define RECORD_FULL_FILE_MAGIC	netorder32(0x20091016)
 
+#define RECORD_MEMORY_XMALLOC_THRESHOLD 0x1000
+
 /* These are the core structs of the process record functionality.
 
    A record_full_entry is a record of the value change of a register
@@ -726,7 +728,11 @@ record_full_exec_insn (struct regcache *regcache,
 	/* Nothing to do if the entry is flagged not_accessible.  */
         if (!entry->u.mem.mem_entry_not_accessible)
           {
-            gdb_byte *mem = (gdb_byte *) alloca (entry->u.mem.len);
+            gdb_byte *mem;
+	    if (entry->u.mem.len >= RECORD_MEMORY_XMALLOC_THRESHOLD)
+	      mem = (gdb_byte *) xmalloc (entry->u.mem.len);
+	    else
+	      mem = (gdb_byte *) alloca (entry->u.mem.len);
 
             if (record_debug > 1)
               fprintf_unfiltered (gdb_stdlog,
@@ -771,6 +777,9 @@ record_full_exec_insn (struct regcache *regcache,
 		      record_full_stop_reason = TARGET_STOPPED_BY_WATCHPOINT;
 		  }
               }
+
+	    if (entry->u.mem.len >= RECORD_MEMORY_XMALLOC_THRESHOLD)
+	      xfree(mem);
           }
       }
       break;
-- 
2.6.2


             reply	other threads:[~2015-11-02 18:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-02 18:42 Marcin Kościelnicki [this message]
2015-11-03 17:31 ` Ulrich Weigand
2015-11-03 17:36   ` Joel Brobecker
2015-11-03 18:11     ` [PATCH v2] gdb/record-full: Use xmalloc instead of alloca for temporary memory storage Marcin Kościelnicki
2015-11-04 14:21       ` Ulrich Weigand

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=1446489704-3173-1-git-send-email-koriakin@0x04.net \
    --to=koriakin@0x04.net \
    --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