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

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

[ERIC HO]

Got an update from the bash maintainer that the fix will be in the next readline release.


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.

Eric.

--
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

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

[Dave Korn]

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

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

[ERIC HO]

Thanks Dave for the steps to identify looping routines. Much appreciated!

Eric

--
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

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

[ERIC HO]

I downloaded the readline source and reviewed the looping rountines identified. It seems that the loop heappens when it is a null command line. If the command line contains some characters, the loop does not happen. I'm not a  expert in C so I reported to the readline maintainer who responded with the following very quickly (thanks Chet!):

**
Thanks for the report.

I'm surprised it does anything at all, and I'm not surprised that it loops.
That should return immediately without doing anything, since there is no
previous search to repeat.

You end up searching in an undefined direction (dir == 0) for an empty
string, and basically stop if the empty string happens to match at the
end of the line (_rl_char_search_internal defaults, by chance, to searching
forward).  The bounds checks will fail, since they include checks for
`dir' which only test the defined range of values.  The contents of
_rl_vi_last_search_mbchar could also be random on cygwin, though the
_rl_vi_last_search_mblen should always be 0, so that should not matter.

Anyway, the right fix is to check to make sure `dir' is in the defined
range.  I suppose I could check for searching for NULL also.

**
I'm just about giving up resolving this issue.
Thanks for those who spent time helping on this issue.

--
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