X-Spam-Check-By: sourceware.org
From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
References: <evebhg$f38$1 AT sea DOT gmane DOT org>
Subject: RE: Status of hstrerror() and h_errno in cygwin and one more important  question
Date: Mon, 9 Apr 2007 23:50:19 +0100
Message-ID: <004801c77af9$7327ebf0$2e08a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <evebhg$f38$1@sea.gmane.org>
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

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

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

  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
-- 
Can't think of a witty .sigline today....


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