This is the mail archive of the
cygwin
mailing list for the Cygwin project.
RE: Status of hstrerror() and h_errno in cygwin and one more important question
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: <cygwin at cygwin dot com>
- Date: Mon, 9 Apr 2007 23:50:19 +0100
- Subject: RE: Status of hstrerror() and h_errno in cygwin and one more important question
- References: <evebhg$f38$1@sea.gmane.org>
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/