Status of hstrerror() and h_errno in cygwin and one more important question
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
>> 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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin