From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Pedro Alves <palves@redhat.com>
Cc: Hui Zhu <teawater@gmail.com>,
gdb-patches ml <gdb-patches@sourceware.org>,
Joel Brobecker <brobecker@adacore.com>
Subject: [patch+7.6] [TUI] Fix scrolling crash 7.6 regression [Re: [PATCH] Fix gdb crash with tui]
Date: Wed, 13 Mar 2013 18:55:00 -0000 [thread overview]
Message-ID: <20130313185456.GA18563@host2.jankratochvil.net> (raw)
In-Reply-To: <513F7592.2080902@redhat.com>
On Tue, 12 Mar 2013 19:36:02 +0100, Pedro Alves wrote:
> So before, tui-out had the hack to call tui_show_source
> whenever a string "file" was being output. Are there any
> other cases where we print a "file" string, but not a "filename"
typo: "fullname"
> string? If so, that may have caused a TUI regression.
I was verifying print_source_lines_base is surprisingly really the only case
from which the output is caught by tui_field_string. tui_field_string
together with tui_field_int required that "line" precedes "file" on the same
line. While every other GDB output normally prints "line" only after "file"
is output. (Currently everything is s/"file"/"fullname"/.)
> but the patch also made it so that tui_field_string is called
> twice: once for "file", and another for "filename". And "file",
typo: "fullname"
> having to special handling, causes tui_field_string to reach:
>
> if (fldname && data->line > 0 && strcmp (fldname, "fullname") == 0)
> {
> .,..
> }
>
> // ... this .... // ######
>
> data->start_of_line++;
>
> (*cli_ui_out_impl.field_string) (uiout, fldno,
> width, align,
> fldname, string);
> }
>
> And call the cli's field_string output, which goes
> the the console window, which I guess causes the flashes
> I see under valgrind,
That's true but I expect there has to be output a lot of other garbage like
"\tin " or "\n" so I did not consider "file" to be significant. I guess the
same crash could happen before just after much more scrollings.
> and fills up the pagination, ultimately causing the pagination prompt and
> the crash as consequence of that being unexpected.
I still do not have the crash reproducible, I even tried to tune stty size.
> Another bug that this caused (or rather another manifestation
> of the bug), is that when you scroll up/down, you see the
> highlighted line disappear rather than following the scroll.
> Before the patch it worked correctly.
It is an unrelated bug but regressed by the same patch. Going to post a patch
for it as a second one.
> But I don't know what motivated that change in the first place.
The motivation was to fix incorrect TUI handling of source files with the same
basename but different dirname, as was demonstrated in:
[patchv2 8/11] TUI: source "file" -> "fullname"
http://sourceware.org/ml/gdb-patches/2013-01/msg00665.html
Message-ID: <20130127223625.GI15252@host2.jankratochvil.net>
I am unable to test this specific patch, I at least understand how the
original Hui's patch should have worked. But it regressed MI output so I have
fixed that.
No regressions on {x86_64,x86_64-m32,i686}-fedora19pre-linux-gnu but that does
not say much for TUI.
Thanks,
Jan
2013-03-13 Hui Zhu <hui_zhu@mentor.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
* source.c (print_source_lines_base): Suppress "file" for TUI.
diff --git a/gdb/source.c b/gdb/source.c
index f5949e6..828d953 100644
--- a/gdb/source.c
+++ b/gdb/source.c
@@ -1344,11 +1344,15 @@ print_source_lines_base (struct symtab *s, int line, int stopline,
{
ui_out_field_int (uiout, "line", line);
ui_out_text (uiout, "\tin ");
- ui_out_field_string (uiout, "file",
- symtab_to_filename_for_display (s));
- /* TUI expects the "fullname" field. While it is
- !ui_out_is_mi_like_p compared to CLI it is !ui_source_list. */
+ /* CLI expects only the "file" field. TUI expects only the
+ "fullname" field (and TUI does break if "file" is printed).
+ MI expects both the fields. ui_source_list is set only for CLI,
+ not for TUI. */
+ if (ui_out_is_mi_like_p (uiout)
+ || ui_out_test_flags (uiout, ui_source_list))
+ ui_out_field_string (uiout, "file",
+ symtab_to_filename_for_display (s));
if (ui_out_is_mi_like_p (uiout)
|| !ui_out_test_flags (uiout, ui_source_list))
{
@@ -1356,6 +1360,7 @@ print_source_lines_base (struct symtab *s, int line, int stopline,
ui_out_field_string (uiout, "fullname", fullname);
}
+
ui_out_text (uiout, "\n");
}
next prev parent reply other threads:[~2013-03-13 18:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-09 14:14 [PATCH] Fix gdb crash with tui Hui Zhu
2013-03-11 19:25 ` Jan Kratochvil
2013-03-12 3:15 ` Hui Zhu
2013-03-12 12:22 ` Hui Zhu
2013-03-12 12:37 ` Jan Kratochvil
2013-03-12 13:21 ` Hui Zhu
2013-03-12 14:21 ` Hui Zhu
2013-03-12 16:04 ` Pedro Alves
2013-03-12 16:35 ` Pedro Alves
2013-03-12 18:36 ` Pedro Alves
2013-03-12 18:42 ` Pedro Alves
2013-03-13 18:55 ` Jan Kratochvil [this message]
2013-03-14 1:46 ` [patch+7.6] [TUI] Fix scrolling crash 7.6 regression [Re: [PATCH] Fix gdb crash with tui] Hui Zhu
2013-03-14 12:33 ` Pedro Alves
2013-03-14 14:41 ` [commit+7.6] " Jan Kratochvil
2013-03-14 14:57 ` Pedro Alves
2013-03-13 18:55 ` [patch+7.6] [TUI] Fix scrolling missing '>' " Jan Kratochvil
2013-03-14 1:46 ` Hui Zhu
2013-03-14 12:53 ` Pedro Alves
2013-03-14 14:44 ` [commit+7.6] " Jan Kratochvil
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=20130313185456.GA18563@host2.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=teawater@gmail.com \
/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