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

[Eric Lilja <mindcooler at gmail 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/