Re: bash/readline spinout in vi command mode (fix identified)

[Dave Korn <dave.korn.cygwin@googlemail.com>]

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 6.8.0.20080328-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
> nd)...done.
> Loaded symbols for /win/c/WINNT/system32/ntdll.dll
> Reading symbols from /usr/bin/cygwin1.dll...Reading symbols from /usr/bin/cygwin
> 1.dbg...done.
> done.
> 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 ?? ()
> (gdb)

  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.

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple