This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 1/2] PR gdb/20604 - fix "quit" when an invalid expression is used
- From: Pedro Alves <palves at redhat dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Tom Tromey <tom at tromey dot com>, gdb-patches at sourceware dot org
- Date: Thu, 3 Nov 2016 11:21:13 +0000
- Subject: Re: [RFA 1/2] PR gdb/20604 - fix "quit" when an invalid expression is used
- Authentication-results: sourceware.org; auth=none
- References: <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