X-Spam-Check-By: sourceware.org To: cygwin@cygwin.com From: Eric Lilja Subject: Re: Status of hstrerror() and h_errno in cygwin and one more important question Date: Tue, 10 Apr 2007 09:07:26 +0200 Lines: 89 Message-ID: References: <004801c77af9$7327ebf0$2e08a8c0@CAM.ARTIMI.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) In-Reply-To: <004801c77af9$7327ebf0$2e08a8c0@CAM.ARTIMI.COM> X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.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/