Status of hstrerror() and h_errno in cygwin and one more important question

Eric Lilja
Tue Apr 10 07:07:00 GMT 2007

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:
Problem reports:

More information about the Cygwin mailing list