From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108126 invoked by alias); 20 Jun 2015 13:29:15 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 108117 invoked by uid 89); 20 Jun 2015 13:29:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yh0-f53.google.com Received: from mail-yh0-f53.google.com (HELO mail-yh0-f53.google.com) (209.85.213.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 20 Jun 2015 13:29:13 +0000 Received: by yhan67 with SMTP id n67so89965108yha.3 for ; Sat, 20 Jun 2015 06:29:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.129.110.68 with SMTP id j65mr25782175ywc.86.1434806951476; Sat, 20 Jun 2015 06:29:11 -0700 (PDT) Received: by 10.13.195.4 with HTTP; Sat, 20 Jun 2015 06:29:11 -0700 (PDT) Date: Sat, 20 Jun 2015 13:29:00 -0000 Message-ID: Subject: gdb arbitrarily starting threads From: "William M. (Mike) Miller" To: cygwin@cygwin.com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00308.txt.bz2 I have a single-threaded executable that has a number of debug-print routines that can be called interactively in the debugger to display data structures to stderr. Something has changed in gdb/gcc/Cygwin during the last year or so (I don't update my installation very often) so that when I call one of these functions, _sometimes_ gdb will start a new thread and put my current thread into "running" status, so that I can't step, etc. (although the thread isn't actually running). Here's the scenario: 1) I say "gdb xxx.exe", set a breakpoint, and run. When I hit the breakpoint, "info threads" shows me two threads, one for my executable and one with some _cygtls/cygthread/ntdll frames; both are stopped. 2) I say "up" a couple of times, then "p db_foo(p)" (where db_foo is one of these debug-print routines that displays to stderr the data structure pointed to by "p"). Sometimes, but not always, gdb will respond with [New Thread 1436.0x1f00] and although a "bt" will show the stack as still stopped at the breakpoint, "info threads" will show all threads as "(running)", and typing "n" is met with the error, Cannot execute this command while the selected thread is running. (Actually, for the first time just now, while running my scenario to make sure I got all the details right for this email, I saw gdb start a new thread in response to a "next" command -- (gdb) n [New Thread 1436.0x1a0c] after I had done a "p db_foo(p)" a couple of times without seeing a new thread created, so apparently it's not just invoking one of these debug-print functions that can result in this behavior.) Changing to one of the newly-created threads reveals this stack trace: #0 0x7733df6c in ntdll!ZwWaitForWorkViaWorkerFactory () from /c/WINDOWS/SYSTEM32/ntdll.dll #1 0x77320153 in ntdll!RtlRunOnceBeginInitialize () from /c/WINDOWS/SYSTEM32/ntdll.dll #2 0x6100626b in _cygtls::call2(unsigned long (*)(void*, void*), void*, void*) () from /usr/bin/cygwin1.dll #3 0x61006306 in _cygtls::call(unsigned long (*)(void*, void*), void*) () from /usr/bin/cygwin1.dll #4 0x610828d8 in threadfunc_fe(void*) () from /usr/bin/cygwin1.dll #5 0x74be7c04 in KERNEL32!BaseThreadInitThunk () from /c/WINDOWS/SYSTEM32/KERNEL32.DLL #6 0x7735ad1f in ntdll!RtlInitializeExceptionChain () from /c/WINDOWS/SYSTEM32/ntdll.dll #7 0x7735acea in ntdll!RtlInitializeExceptionChain () from /c/WINDOWS/SYSTEM32/ntdll.dll #8 0x00000000 in ?? () Any ideas on what I can do to avoid this annoying behavior or to regain control of my debugging session after it occurs? I'm running 32-bit Cygwin on Windows 8.1. Thanks. -- William M. (Mike) Miller | Edison Design Group william.m.miller@gmail.com -- 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