[Bug cli/21218] Regression: GDB dumps core when escaping newline in multi line command

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21218

--- Comment #2 from Pedro Alves <palves at redhat dot com> ---
I have a local fix.  Turns out that commit ended up exposing a "latent" bug. 
The problem is that gdb_readline_wrapper ends up calling display_gdb_prompt
with a NULL prompt parameter, which has special meaning - it signals that we're
printing the primary prompt, when what we want is a secondary prompt.

While tightening the test, I noticed that the commit before the one that
exposed the crash also behaved incorrectly:

 PASS: gdb.base/commands.exp: commands
 print \
 (gdb) argc
 FAIL: gdb.base/commands.exp: input line split with backslash (timeout)

I.e., gdb wouldn't crash, but it'd print the gdb prompt when it shouldn't.

Going further back, to try to find the commit that introduced that problem, in
order to try to confirm what I think GDB should be printing after the \ (i.e.,
nothing, instead of a ">" or something else), I found that that problem was
originally introduced right when gdb_readline_wrapper was originally added:

commit 782a7b8ef9c096357073a9c177fb1e21b282cec0
Author:     Daniel Jacobowitz <dan@debian.org>
AuthorDate: Wed Jan 3 21:46:12 2007 +0000
Commit:     Daniel Jacobowitz <dan@debian.org>
CommitDate: Wed Jan 3 21:46:12 2007 +0000

    2007-01-03  Jan Kratochvil  <jan.kratochvil@redhat.com>
            Daniel Jacobowitz  <dan@codesourcery.com>

And with that commit, gdb started crashing in this use case:

(gdb) commands
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>print \

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106             movdqu  (%rax), %xmm12
(top-gdb) bt
#0  0x00007ffff6f256fa in strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x00000000004d8cbb in display_gdb_prompt (new_prompt=0x0) at
src/gdb/event-top.c:298
#2  0x0000000000448ca7 in gdb_readline_wrapper (prompt=0x0) at
src/gdb/top.c:806
#3  0x0000000000449178 in command_line_input (prompt_arg=0x7fffffffd290 ">",
repeat=1, annotation_suffix=0x61295d "commands")
    at src/gdb/top.c:1011

Kind of funny this issue survived so long unnoticed and with different
manifestations.

Just before that commit, GDB behaved like this:

(gdb) commands
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>print \
1
>end
(gdb) 

... which is what my (yet-unposted) patch will restore GDB back to.

-- 
You are receiving this mail because:
You are on the CC list for the bug.