aboutsummaryrefslogtreecommitdiff
path: root/cpu/cris.cpu
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2014-10-29 11:57:03 +0000
committerPedro Alves <palves@redhat.com>2014-10-29 14:54:17 +0000
commit6e5d7f393ed899c8e980b238be3cf23ec296e3f6 (patch)
tree93bfa76efd4a29ed3487adff0485d58c880396a9 /cpu/cris.cpu
parent1e1e619b6b382f9b354d78018ddb73f0070375d2 (diff)
downloadgdb-6e5d7f393ed899c8e980b238be3cf23ec296e3f6.zip
gdb-6e5d7f393ed899c8e980b238be3cf23ec296e3f6.tar.gz
gdb-6e5d7f393ed899c8e980b238be3cf23ec296e3f6.tar.bz2
Fix uninitialized value access when very first GDB command entered is <RET>
While running GDB under Valgrind, I noticed that if the very first command entered is just <RET>, GDB accesses an uninitialized value: $ valgrind ./gdb -q -nx ==26790== Memcheck, a memory error detector ==26790== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==26790== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==26790== Command: ./gdb -q -nx ==26790== (gdb) ==26790== Conditional jump or move depends on uninitialised value(s) ==26790== at 0x619DFC: command_line_handler (event-top.c:588) ==26790== by 0x7813D5: rl_callback_read_char (callback.c:220) ==26790== by 0x6194B4: rl_callback_read_char_wrapper (event-top.c:166) ==26790== by 0x61988A: stdin_event_handler (event-top.c:372) ==26790== by 0x61847D: handle_file_event (event-loop.c:762) ==26790== by 0x617964: process_event (event-loop.c:339) ==26790== by 0x617A2B: gdb_do_one_event (event-loop.c:403) ==26790== by 0x617A7B: start_event_loop (event-loop.c:428) ==26790== by 0x6194E6: cli_command_loop (event-top.c:181) ==26790== by 0x60F86B: current_interp_command_loop (interps.c:317) ==26790== by 0x610A34: captured_command_loop (main.c:321) ==26790== by 0x60C728: catch_errors (exceptions.c:237) ==26790== (gdb) It's this check here: /* If we just got an empty line, and that is supposed to repeat the previous command, return the value in the global buffer. */ if (repeat && p == linebuffer && *p != '\\') { The problem is that linebuffer's contents were never initialized at this point. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> * event-top.c (command_line_handler): Clear the first byte of linebuffer, when it is first allocated.
Diffstat (limited to 'cpu/cris.cpu')
0 files changed, 0 insertions, 0 deletions