binutils-gdb/gdb/python/py-gdb-readline.c
Simon Marchi f8631e5e04 gdb: remove static buffer in command_line_input
[I sent this earlier today, but I don't see it in the archives.
Resending it through a different computer / SMTP.]

The use of the static buffer in command_line_input is becoming
problematic, as explained here [1].  In short, with this patch [2] that
attempt to fix a post-hook bug, when running gdb.base/commands.exp, we
hit a case where we read a "define" command line from a script file
using command_command_line_input.  The command line is stored in
command_line_input's static buffer.  Inside the define command's
execution, we read the lines inside the define using command_line_input,
which overwrites the define command, in command_line_input's static
buffer.  After the execution of the define command, execute_command does
a command look up to see if a post-hook is registered.  For that, it
uses a now stale pointer that used to point to the define command, in
the static buffer, causing a use-after-free.  Note that the pointer in
execute_command points to the dynamically-allocated buffer help by the
static buffer in command_line_input, not to the static object itself,
hence why we see a use-after-free.

Fix that by removing the static buffer.  I initially changed
command_line_input and other related functions to return an std::string,
which is the obvious but naive solution.  The thing is that some callees
don't need to return an allocated string, so this this an unnecessary
pessimization.  I changed it to passing in a reference to an std::string
buffer, which the callee can use if it needs to return
dynamically-allocated content.  It fills the buffer and returns a
pointers to the C string inside.  The callees that don't need to return
dynamically-allocated content simply don't use it.

So, it started with modifying command_line_input as described above, all
the other changes derive directly from that.

One slightly shady thing is in handle_line_of_input, where we now pass a
pointer to an std::string's internal buffer to readline's history_value
function, which takes a `char *`.  I'm pretty sure that this function
does not modify the input string, because I was able to change it (with
enough massaging) to take a `const char *`.

A subtle change is that we now clear a UI's line buffer using a
SCOPE_EXIT in command_line_handler, after executing the command.
This was previously done by this line in handle_line_of_input:

  /* We have a complete command line now.  Prepare for the next
     command, but leave ownership of memory to the buffer .  */
  cmd_line_buffer->used_size = 0;

I think the new way is clearer.

[1] https://inbox.sourceware.org/gdb-patches/becb8438-81ef-8ad8-cc42-fcbfaea8cddd@simark.ca/
[2] https://inbox.sourceware.org/gdb-patches/20221213112241.621889-1-jan.vrany@labware.com/

Change-Id: I8fc89b1c69870c7fc7ad9c1705724bd493596300
Reviewed-By: Tom Tromey <tom@tromey.com>
2022-12-15 21:49:29 -05:00

115 lines
3.2 KiB
C

/* Readline support for Python.
Copyright (C) 2012-2022 Free Software Foundation, Inc.
This file is part of GDB.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
#include "defs.h"
#include "python-internal.h"
#include "top.h"
#include "cli/cli-utils.h"
/* Readline function suitable for PyOS_ReadlineFunctionPointer, which
is used for Python's interactive parser and raw_input. In both
cases, sys_stdin and sys_stdout are always stdin and stdout
respectively, as far as I can tell; they are ignored and
command_line_input is used instead. */
static char *
gdbpy_readline_wrapper (FILE *sys_stdin, FILE *sys_stdout,
#if PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 4
const char *prompt)
#else
char *prompt)
#endif
{
int n;
const char *p = NULL;
std::string buffer;
char *q;
try
{
p = command_line_input (buffer, prompt, "python");
}
/* Handle errors by raising Python exceptions. */
catch (const gdb_exception &except)
{
/* Detect user interrupt (Ctrl-C). */
if (except.reason == RETURN_QUIT)
return NULL;
/* The thread state is nulled during gdbpy_readline_wrapper,
with the original value saved in the following undocumented
variable (see Python's Parser/myreadline.c and
Modules/readline.c). */
PyEval_RestoreThread (_PyOS_ReadlineTState);
gdbpy_convert_exception (except);
PyEval_SaveThread ();
return NULL;
}
/* Detect EOF (Ctrl-D). */
if (p == NULL)
{
q = (char *) PyMem_RawMalloc (1);
if (q != NULL)
q[0] = '\0';
return q;
}
n = strlen (p);
/* Copy the line to Python and return. */
q = (char *) PyMem_RawMalloc (n + 2);
if (q != NULL)
{
strcpy (q, p);
q[n] = '\n';
q[n + 1] = '\0';
}
return q;
}
/* Initialize Python readline support. */
void
gdbpy_initialize_gdb_readline (void)
{
/* Python's readline module conflicts with GDB's use of readline
since readline is not reentrant. Ideally, a reentrant wrapper to
GDB's readline should be implemented to replace Python's readline
and prevent conflicts. For now, this file implements a
sys.meta_path finder that simply fails to import the readline
module. */
if (PyRun_SimpleString ("\
import sys\n\
\n\
class GdbRemoveReadlineFinder:\n\
def find_module(self, fullname, path=None):\n\
if fullname == 'readline' and path is None:\n\
return self\n\
return None\n\
\n\
def load_module(self, fullname):\n\
raise ImportError('readline module disabled under GDB')\n\
\n\
sys.meta_path.append(GdbRemoveReadlineFinder())\n\
") == 0)
PyOS_ReadlineFunctionPointer = gdbpy_readline_wrapper;
}