X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Eric Lilja <mindcooler AT gmail DOT com>
Subject:  Re: Status of hstrerror() and h_errno in cygwin and one more important   question
Date:  Tue, 10 Apr 2007 09:07:26 +0200
Lines: 89
Message-ID: <evfd39$9d4$1@sea.gmane.org>
References:  <evebhg$f38$1 AT sea DOT gmane DOT org> <004801c77af9$7327ebf0$2e08a8c0 AT CAM DOT ARTIMI DOT COM>
Mime-Version:  1.0
Content-Type:  text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding:  7bit
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
In-Reply-To: <004801c77af9$7327ebf0$2e08a8c0@CAM.ARTIMI.COM>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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

Dave Korn wrote:
> On 09 April 2007 22:35, Eric Lilja wrote:
> 
>> I'm developing a very simple IRC bot (written in C++) with a gui using
>> the cygwin tools.
> 
>> Also, and more importantly, I'm having a weird core dump in my
>> application. The program is very simple, when launched you can connect
>> to an irc server (which one is hard coded right now). A new thread is
>> spawned upon connection that handles all communication with the irc
>> server, any messages are displayed in the gui. When you are connected
>> you may disconnect and connect again if you wish. The threading part is
>> encapsulated in a class that contains another class that encapsulates
>> the socket code. This thread class dynamically allocated. The core dump
>> happens when these things are true:
>> You connect
>> You stay connected long enough to receive the entire MOTD.
>> You disconnect.
>> You exit the program, main thread calls delete on the thread class
>> object <--- core dump here.
> 
>   Ok, that's really simple: your code has a bug.  Most likely you're calling
> free() or delete on something that wasn't originally allocated.

I wrote this reply in a personal email to Dave shortly after his post 
because I didn't want to do a proper reply until I could see my post 
(and his) on gmane using my newsreader.

Thanks Dave, seems I had a double delete! The program allocates
the thread object dynamically at startup and deallocates it when
exiting (under WM_CREATE/WM_DESTROY, respectively, if you're familiar
with the Win32 API). But I noticed, after reading your reply, I had
put deletion code under my code that handles if the user selects exit
from the menu (which in turns destroys the windows generating a
WM_DESTROY) as well! Thus I had a double delete if I exited the
program using that menu item (which I was doing when testing, didn't
occur to me to test by just pressing the 'x').

>  
>> If you disconnect earlier or exit without first explicitly
>> disconnecting, it does not core dump. Also, it does not core dump if you
>> skip the delete.
> 
>   That agrees with what I'm guessing.  It helps you narrow down the diagnosis:
> it's something that only get set once you've been through the initial protocol
> exchanges.
> 
>> Since the program is exiting its memory is bound to be
>> returned anyway, but this still annoys me to no end. I just wrote a
>> console version which I thought I could use as a simpler test case but
>> that version does not core dump, heh.
>>
>> Afaics, cygwin doesn't have a mailing list for those developing their
>> own programs under cygwin and need support. 
> 
>   Absolutely it does, and this is it.

Oh, it is? Well, that's great! But sometimes, I've seen such questions 
about problems with programs developed using the cygwin tools getting a 
response like "you have a basic c++ problem, basic bash problem and this 
is off-topic". My particular problem turned out, as I wrote above, to be 
a double delete and that would have happened had this been a pure win32 
program (no pthreads or cygwin sockets).

> 
>> Do you have any idea where I
>> can turn for help and maybe some suggestions on how I can obtain more
>> information about exactly why it craps out? My gdb skills are abysmal,
>> I'm afraid. I'm decent with the visual studio debugger but I just can't
>> seem to get efficient with gdb. Even the simplest things like keeping
>> track of exactly which line I am at in the code deludes me. And that's
>> even with running emacs' gdb mode!
> 
>   :)  Yeh, gdb can be not-exactly-friendly.  I find insight easier to use
> because you don't have to learn the gdb commandline syntax.

I investigated insight years ago (yes, it's been years and I still am at 
the first step regarding mastering gdb =/), I will look at it again.

> 
>   Like I say, look for free-ing something that's static, or double-freeing
> something first.  Make sure you NULL out every pointer when you release it,
> that can often help with this sort of bug.  Maybe try using a malloc debugging
> library based on wrappers.
> 
>     cheers,
>       DaveK

- Eric


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