This is the mail archive of the
mailing list for the Cygwin project.
Re: bash/readline spinout in vi command mode (fix identified)
- From: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: cygwin at cygwin dot com
- Date: Sun, 25 Apr 2010 19:14:15 +0100
- Subject: Re: bash/readline spinout in vi command mode (fix identified)
- References: <firstname.lastname@example.org>
On 25/04/2010 17:01, ERIC HO wrote:
> Got an update from the bash maintainer that the fix will be in the next
> readline release.
Good work, thanks for following through with the upstreams.
> Hi Dave, in your one update that you used gdb to identify the looping
> readline routines. I'd appreciate if you could show me the steps to do this
> so that I can do similar debugging myself next time. Thanks.
Yep, sure. First I followed your procedure to reproduce the problem: launch
"mintty -", run "set -o vi", press shift+F12 and it starts looping.
Using windows task manager, in the processes tab and sorting by the "CPU
Time" column, I identified the windows PID of the task taking all the cpu time
- in this case, 3036, and use ps to find the corresponding cygwin pid:
> $ ps | grep 3036
> 4204 3908 4204 3036 6 500 19:07:03 /usr/bin/bash
Then the syntax to attach gdb to a running program is this:
> $ gdb --pid 4204
> GNU gdb 188.8.131.5280328-cvs (cygwin-special)
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-pc-cygwin".
> Attaching to process 3036
> [New thread 3036.0xa60]
> [New thread 3036.0x1174]
> [New thread 3036.0xbe0]
> [New thread 3036.0xff8]
> [New thread 3036.0x7f0]
> Reading symbols from /usr/bin/bash...(no debugging symbols found)...done.
> Reading symbols from /win/c/WINNT/system32/ntdll.dll...(no debugging symbols fou
> Loaded symbols for /win/c/WINNT/system32/ntdll.dll
> Reading symbols from /usr/bin/cygwin1.dll...Reading symbols from /usr/bin/cygwin
> Loaded symbols for /usr/bin/cygwin1.dll
> Reading symbols from /win/c/WINNT/system32/ADVAPI32.DLL...done.
> Loaded symbols for /win/c/WINNT/system32/ADVAPI32.DLL
> Reading symbols from /win/c/WINNT/system32/KERNEL32.dll...done.
> Loaded symbols for /win/c/WINNT/system32/KERNEL32.dll
> Reading symbols from /win/c/WINNT/system32/RPCRT4.dll...done.
> Loaded symbols for /win/c/WINNT/system32/RPCRT4.dll
> Reading symbols from /usr/bin/cygintl-8.dll...done.
> Loaded symbols for /usr/bin/cygintl-8.dll
> Reading symbols from /usr/bin/cygiconv-2.dll...done.
> Loaded symbols for /usr/bin/cygiconv-2.dll
> Reading symbols from /usr/bin/cyggcc_s-1.dll...done.
> Loaded symbols for /usr/bin/cyggcc_s-1.dll
> Reading symbols from /usr/bin/cygreadline7.dll...done.
> Loaded symbols for /usr/bin/cygreadline7.dll
> Reading symbols from /usr/bin/cygncurses-9.dll...done.
> Loaded symbols for /usr/bin/cygncurses-9.dll
[ ... snip ... ]
> Loaded symbols for /win/c/WINNT/System32/winrnr.dll
> [Switching to thread 3036.0x7f0]
When you attach to a running process, gdb injects a thread that calls a
debug breakpoint, and when the process is attached, gdb defaults to that
thread. I wanted to see what's going on in the main thread, so I switch to it
using "thread 1" and run the backtrace command "bt" to see where it's at:
> (gdb) thread 1
> [Switching to thread 1 (thread 3036.0xa60)]#0 0x6afdb8e5 in rl_is_mbchar_matche
> d () from /usr/bin/cygreadline7.dll
> (gdb) bt
> #0 0x6afdb8e5 in rl_is_mbchar_matched () from /usr/bin/cygreadline7.dll
> #1 0x6afd570c in rl_char_search_internal () from /usr/bin/cygreadline7.dll
> #2 0x6afc3474 in rl_vi_char_search () from /usr/bin/cygreadline7.dll
> #3 0x6afc16ba in rl_dispatch_subseq () from /usr/bin/cygreadline7.dll
> #4 0x6afc1a75 in rl_dispatch () from /usr/bin/cygreadline7.dll
> #5 0x6afd7c05 in rl_arg_dispatch () from /usr/bin/cygreadline7.dll
> #6 0x6afd7d79 in rl_arg_callback () from /usr/bin/cygreadline7.dll
> #7 0x6afc16ba in rl_dispatch_subseq () from /usr/bin/cygreadline7.dll
> #8 0x6afc1a75 in rl_dispatch () from /usr/bin/cygreadline7.dll
> #9 0x6afc1e19 in readline_internal_char () from /usr/bin/cygreadline7.dll
> #10 0x6afc2205 in readline () from /usr/bin/cygreadline7.dll
> #11 0x00409791 in ?? ()
> #12 0x006d8ba8 in ?? ()
> #13 0x00430db0 in ?? ()
> #14 0x0022c1f8 in ?? ()
> #15 0x0041fae6 in ?? ()
> #16 0x006c0800 in ?? ()
> #17 0x00000000 in ?? ()
Then to try and localise it a little more, I repeatedly used gdb's "fin"
command, which "fin"ishes running the current function and stops when it returns:
> (gdb) fin
> Run till exit from #0 0x6afdb8e5 in rl_is_mbchar_matched ()
> from /usr/bin/cygreadline7.dll
> 0x6afd570c in rl_char_search_internal () from /usr/bin/cygreadline7.dll
> (gdb) fin
> Run till exit from #0 0x6afd570c in rl_char_search_internal ()
> from /usr/bin/cygreadline7.dll
[ ... hangs again ... ]
So, that tells me that rl_char_search_internal() is the function that's
looping forever, and that rl_is_mbchar_matched() is just one of the things
it's calling in the infinite loop.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple