X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,TW_FD,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Message-ID: <4BD48677.7060806@gmail.com> Date: Sun, 25 Apr 2010 19:14:15 +0100 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: bash/readline spinout in vi command mode (fix identified) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT 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 > 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