X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=3.1 required=5.0 	tests=AWL,BAYES_05,BOTNET,J_CHICKENPOX_13,J_CHICKENPOX_43,J_CHICKENPOX_44,J_CHICKENPOX_66,RDNS_NONE
X-Spam-Check-By: sourceware.org
Message-ID: <499ED1CE.1050803@onevision.de>
Date: Fri, 20 Feb 2009 16:52:46 +0100
From: Roland Schwingel <roland DOT schwingel AT onevision DOT de>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Strange freezes when using gdb (rxvt/mintty but not dos box)
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Hi...

Today I observed a strange freeze when using gdb-6.8-2 (or cvs gdb) 
within cygwin 1.5.25 on 2 different machines.
gdb freezes upon execution of the inferior process when used from within 
mintty/rxvt, but does not freeze when gdb
is invoked from a (conventional) bash inside of a windows DOS box. I 
assume some race conditions/syncronization
issue causing a thread block.

What did I want to do.. I compiled myself a little piece of code (see 
below) to check how different gdb version
behave unwinding the stack on crashes in different threads. The 
application I want to debug is compiled for mingw.

Here comes the code (if someone wants to reproduce):
----------------------------------------------------------------------------------
#include <stdio.h>
#include <windows.h>

void func1(int num);

int var = 23;

void crashIfZero(int num)
{
    var--;

    if (var == 0)
    {
        int *data=0x0;
        printf ("I am thread %d and I will crash now!\n",num);
       
        *data=911;
    }
    else
        printf ("Thread %d: var = %d\n",num,var);       
}

void func4(int num)
{
    Sleep(100);
    crashIfZero(num);
    func1(num);
}

void func3(int num)
{
    Sleep(100);
    crashIfZero(num);
    func4(num);
}

void func2(int num)
{
    Sleep(100);
    crashIfZero(num);
    func3(num);
}

void func1(int num)
{
    Sleep(100);
    crashIfZero(num);
    func2(num);
}

DWORD WINAPI threadFunc(LPVOID param)
{
    int num = *(DWORD *)param;
    printf ("I am thread %d and alive\n");
    func1(num);
}

void makeThreads(int num)
{
    int i;

    for (i=1;i<=num;i++)
    {
        HANDLE threadHandle;
        DWORD  threadId, threadParam = i;
        threadHandle = 
CreateThread(NULL,0,threadFunc,&threadParam,0,&threadId);
       
        if (threadHandle == NULL)
            printf ("Couldn't create thread %d\n",i);
        else
            printf ("Created thread %d with ID: %d\n",i,threadId);
       
        Sleep(50);
    }
   
    printf ("Created %d Threads....\n",num);
    Sleep(200000);
}

int main(int argc,char **argv)
{
    setbuf(stdout,NULL);
    setbuf(stderr,NULL);

    printf ("test gdb stack tracing during a crash\n");
    makeThreads(3);
}
----------------------------------------------------------------------------------

Compiled using: gcc -g -mno-cygwin gdb_crash.c -o gdb_crash
Invoking gdb: gdb gdb_crash.exe
The (gdb) prompt appears just fine... When I now enter "r" to run the code
gdb prints the first lines but then freezes when gdb ist started using 
mintty/rxvt.

$ gdb gdb_crash.exe
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"...
(gdb) r
Starting program: gdb_crash.exe
[New thread 2060.0xca4]
test gdb stack tracing during a crash
C[New thread 2060.0xfdc]
reated thread 1 with ID: 4060
I am thread 1 and alive
C

That's it... When I do this from cygwin bash inside of a dos box 
everything is fine.
I assume it is happening during the phase when gdb wants to print the 
next "[New thread 2060.0x....]" line
Please not that that the "[New thread 2060.0x....]" line is in between 
of the output of the "Created thread 1 with ..." line.
When running it from dos box the lines are not mixed. Everything is fine.

While this is curious enough it is still not the whole story. I made my 
tests on a Intel Quadcore (Q9550). The problems
DO NOT happen on a AMD Singlecore maschine (XP 2800+). The cygwin is 
100% identical on both systems
(copied bit by bit from machine A to machine B). Both systems run 
Windows XP SP 3 32bit.
When I limit gdb to just use on cpu core (using windows taskmanager) 
before typing 'r' everything works
too on the quad core... In this case both gdb and my testcode only use 
one cpu core. But this is not
really what I want to do...

So I assume some threading issues here in communication with the 
console/terminal from multiple threads...
But why does it work with DOS box and not using mintty/rxvt??? When I 
run my code without gdb it runs
well even on the quad core.

Thanks for any help,

Roland


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