public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [RFA 1/2] PR gdb/20604 - fix "quit" when an invalid expression is used
Date: Thu, 03 Nov 2016 11:21:00 -0000	[thread overview]
Message-ID: <6ffd9182-dfe4-ebaf-8b47-97e30ed21913@redhat.com> (raw)
In-Reply-To: <20161026194417.E142310FDC2@oc8523832656.ibm.com>

On 10/26/2016 08:44 PM, Ulrich Weigand wrote:

> I just noticed that this test case completely breaks my daily testing.
> When running the quit.exp test, GDB will hang in a way that it isn't
> even killed by the timeout logic, and will keep blocking further
> execution forever.
> 
> Attaching to GDB shows it blocked in an ioctl with this backtrace
> (which for some reason doesn't even include the quit path ...)
> 
> #0  0x0feea474 in tcsetattr () from /lib/libc.so.6
> #1  0x102d7004 in _set_tty_settings (tty=0, tiop=0x10641adc) at /home/uweigand/dailybuild/spu-tc-2016-10-25/binutils-gdb-head/binutils-gdb/readline/rltty.c:476
> #2  0x102d70e0 in set_tty_settings (tty=<value optimized out>, tiop=<value optimized out>)
>     at /home/uweigand/dailybuild/spu-tc-2016-10-25/binutils-gdb-head/binutils-gdb/readline/rltty.c:490
> #3  0x102d7530 in rl_deprep_terminal () at /home/uweigand/dailybuild/spu-tc-2016-10-25/binutils-gdb-head/binutils-gdb/readline/rltty.c:688
> #4  0x102ea2d4 in rl_callback_read_char () at /home/uweigand/dailybuild/spu-tc-2016-10-25/binutils-gdb-head/binutils-gdb/readline/callback.c:215
> #5  0x1017defc in gdb_rl_callback_read_char_wrapper (client_data=<value optimized out>)

> Note that when running GDB directly, quit works fine.  The problem
> occurs only when running GDB under the DejaGNU framework.

In such cases, I suggest inserting a gdb_interact call in
the testcase and debugging that way.

> Does this ring any bells?  Any thoughts what could cause this?

The [wait -i $gdb_spawn_id] in the test does look dangerous
in the sense that it won't be subject to timeout logic.
So if the previous test fails, that'll likely hang forever.

Other than that, no ideas.  Can you tell from the gdb.log how
far the test went?

Thanks,
Pedro Alves

  reply	other threads:[~2016-11-03 11:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-14 22:59 Tom Tromey
2016-09-14 22:59 ` [RFA 2/2] Make some test names invariant Tom Tromey
2016-09-15 15:16   ` Pedro Alves
2016-09-15 16:46     ` Tom Tromey
2016-09-15 15:06 ` [RFA 1/2] PR gdb/20604 - fix "quit" when an invalid expression is used Pedro Alves
2016-09-21  7:51   ` Tom Tromey
2016-09-21 17:16     ` Pedro Alves
2016-10-26 19:44       ` Ulrich Weigand
2016-11-03 11:21         ` Pedro Alves [this message]
2016-11-07 15:57           ` Ulrich Weigand
2017-10-17 17:28             ` Pedro Alves
2017-10-20 12:55               ` Ulrich Weigand

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=6ffd9182-dfe4-ebaf-8b47-97e30ed21913@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tom@tromey.com \
    --cc=uweigand@de.ibm.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).