public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@redhat.com>
To: gdb-patches@sourceware.org
Cc: Andrew Burgess <aburgess@redhat.com>
Subject: [PATCH] gdb: add test for readline handling very long commands
Date: Fri, 10 Feb 2023 10:42:46 +0000	[thread overview]
Message-ID: <5590ca7146d94722f6ae6b2e96fe92f3ef6b4eab.1676025758.git.aburgess@redhat.com> (raw)

The test added in this commit tests for a long fixed readline issue
relating to long command lines.  A similar patch has existed in the
Fedora GDB tree for several years, but I don't see any reason why this
test would not be suitable for inclusion in upstream GDB.  I've
updated the patch to current testsuite standards.

The test is checking for an issue that was fixed by this readline
patch:

  https://lists.gnu.org/archive/html/bug-readline/2006-11/msg00002.html

Which was merged into readline 6.0 (released ~2010).  The issue was
triggered when the user enters a long command line, which wrapped over
multiple terminal lines.  The crash looks like this:

  free(): invalid pointer

  Fatal signal: Aborted
  ----- Backtrace -----
  0x4fb583 gdb_internal_backtrace_1
          ../../src/gdb/bt-utils.c:122
  0x4fb583 _Z22gdb_internal_backtracev
          ../../src/gdb/bt-utils.c:168
  0x6047b9 handle_fatal_signal
          ../../src/gdb/event-top.c:964
  0x7f26e0cc56af ???
  0x7f26e0cc5625 ???
  0x7f26e0cae8d8 ???
  0x7f26e0d094be ???
  0x7f26e0d10aab ???
  0x7f26e0d124ab ???
  0x7f26e1d32e12 rl_free_undo_list
          ../../readline-5.2/undo.c:119
  0x7f26e1d229eb readline_internal_teardown
          ../../readline-5.2/readline.c:405
  0x7f26e1d3425f rl_callback_read_char
          ../../readline-5.2/callback.c:197
  0x604c0d gdb_rl_callback_read_char_wrapper_noexcept
          ../../src/gdb/event-top.c:192
  0x60581d gdb_rl_callback_read_char_wrapper
          ../../src/gdb/event-top.c:225
  0x60492f stdin_event_handler
          ../../src/gdb/event-top.c:545
  0xa60015 gdb_wait_for_event
          ../../src/gdbsupport/event-loop.cc:694
  0xa6078d gdb_wait_for_event
          ../../src/gdbsupport/event-loop.cc:593
  0xa6078d _Z16gdb_do_one_eventi
          ../../src/gdbsupport/event-loop.cc:264
  0x6fc459 start_event_loop
          ../../src/gdb/main.c:411
  0x6fc459 captured_command_loop
          ../../src/gdb/main.c:471
  0x6fdce4 captured_main
          ../../src/gdb/main.c:1310
  0x6fdce4 _Z8gdb_mainP18captured_main_args
          ../../src/gdb/main.c:1325
  0x44f694 main
          ../../src/gdb/gdb.c:32
  ---------------------

I recreated the above crash by a little light hacking on GDB, and then
linking GDB against readline 5.2.  The above stack trace was generated
from the test included in this patch, and matches the trace that was
included in the original bug report.

It is worth acknowledging that without hacking things GDB has a
minimum requirement of readline 7.0.  This test is not about checking
whether GDB has been built against an older version of readline, it is
about checking that readline doesn't regress in this area.
---
 gdb/testsuite/gdb.base/readline.exp | 40 +++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/gdb/testsuite/gdb.base/readline.exp b/gdb/testsuite/gdb.base/readline.exp
index 73c10f8000f..87225273c25 100644
--- a/gdb/testsuite/gdb.base/readline.exp
+++ b/gdb/testsuite/gdb.base/readline.exp
@@ -205,5 +205,45 @@ save_vars { env(TERM) } {
 	    "p 7" ".* = 7" \
 	    "p 8" ".* = 8" \
 	    "p 9" ".* = 9"
+
+	# Test sending a long command to GDB, a command that requires
+	# multiple terminal lines.  Long ago there was a readline bug
+	# that would cause GDB to crash in this situation.  We force
+	# the bug by setting up a narrow terminal width, and then
+	# sending a long command.
+	clean_restart
+
+	# The number of characters to send in the command.  We
+	# actually send a few more than this; this total is really the
+	# extra characters we add on after sending the command name.
+	set char_total 4500
+	set char_sent 0
+
+	# Adjust the terminal width.
+	gdb_test_no_output "set width 7"
+
+	# Send the command prefix, then lots of additional characters
+	# that create a really long command that wraps over multiple
+	# lines.
+	send_gdb "help X"
+	gdb_test_multiple "" "send long command to GDB" {
+	    -re "X" {
+		incr char_sent
+		if {$char_sent <= $char_total} {
+		    send_gdb "X"
+		    exp_continue
+		}
+	    }
+	    -re "\[ \b\r\n\]" {
+		exp_continue
+	    }
+	}
+
+	# Send the final newline so that GDB will process the command.
+	# Check GDB returns a suitable error.
+	send_gdb "\n"
+	gdb_test "" \
+	    "Undefined command: \"X+\"\\.  Try \"help\"\\." \
+	    "All the characters transferred"
     }
 }

base-commit: 1947a4a4bb7651a4656edceb1f9b246f96f89ebd
-- 
2.25.4


             reply	other threads:[~2023-02-10 10:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-10 10:42 Andrew Burgess [this message]
2023-02-10 14:35 ` Tom Tromey
2023-02-11 17:18   ` Andrew Burgess

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=5590ca7146d94722f6ae6b2e96fe92f3ef6b4eab.1676025758.git.aburgess@redhat.com \
    --to=aburgess@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).