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