X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Eric Lilja <mindcooler AT gmail DOT com>
Subject:  Re: Status of hstrerror() and h_errno in cygwin and one more important     question
Date:  Tue, 10 Apr 2007 09:11:30 +0200
Lines: 123
Message-ID: <evfdat$a56$1@sea.gmane.org>
References:  <evebhg$f38$1 AT sea DOT gmane DOT org> <461AD324 DOT 97CBCE0E AT dessent DOT net>
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: <461AD324.97CBCE0E@dessent.net>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Brian Dessent wrote:
> Eric Lilja wrote:
> 
>> I'm developing a very simple IRC bot (written in C++) with a gui using
>> the cygwin tools. I use Win32 for the gui and I use cygwin sockets and
>> pthreads for communicating with the server.
>>
>> Anyway, I found h_errno/hstrerror() to be useful when dealing with
>> gethostname() errors, but they are marked as obsolete in linux, I think,
>> meaning they could be removed in the future I guess...what is the status
>> for those in cygwin? Is there an alternative I can use right now? I like
>> my socket code to be as portable to a modern linux as possible.
> 
> I wouldn't worry about the gethostname() and friends API going away any
> time soon.  It's true that it's deprecated, but there are so many apps
> out there using it that I can't see it being actually removed any time
> soon.  Until somewhat recently I don't even think Cygwin's getaddrinfo()
> was very functional.
> 
>> 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.
> 
> Yeah, like Dave said you just have to find the bug.  There's no step by
> step process to follow, but if you can reproduce it at will that is at
> least half of the battle.
> 
> I also agree with him that insight is a lot easier to use than gdb.  I
> use it myself for anything nontrivial.  And don't forget that gdb has
> great documentation.  It's all online at
> <http://sourceware.org/gdb/current/onlinedocs/> if you want it in
> HTML/PDF.  The refcard is handy to keep around (though its a bit
> outdated.)
> 
> A couple of general-purpose debugging tips:
> 
> - Try using -gstabs+ or -gdwarf-2 in your CXXFLAGS instead of just -g. 
> The former enables GDB-specific extensions to the old stabs format, the
> latter uses the Dwarf-2 debug format.  Either of these might help when
> stepping through complex C++ code (or code with lots of inlines) where
> the debugger often gets confused, as it allows the compiler to give more
> expressive hints.
> 
> - Consider compiling the code you're debugging with with -O0.  A
> technique I use sometimes when debugging to rebuild just one or a few
> objects without having to reconfigure and rebuild the whole project is
> simply to delete the object(s) of interest and then remake with the
> appropriate *FLAGS overridden, e.g. 'make CXXFLAGS="-gdwarf-2 -O0"'. 
> This lets you quickly change options on a per-module basis without
> having to completely start over each time.  I use this to great effect
> with other flags too, like -save-temps, if I want to inspect the
> assembly output that gcc produced.  Combine this with -fverbose-asm and
> you get extra commentary in the assembler output which helps you see
> which variables correspond to each line of assembler.  You can also
> simply look at a disassembly of an object with "objdump -dS foo.o" which
> gives you a side-by-side view of the disasm and source (as long as the
> object was compiled with debug info.)
> 
> - Try installing the cygwin1.dbg debug symbols in /usr/bin.  Even if you
> aren't actually interested in debugging Cygwin itself, it makes life
> easier.  I think they are included in the cygwin-*-src.tar.bz2 package,
> although you may find pathname translation problems since you're
> unlikely to have the same layout as the person that compiled the
> package.  There is a workaround for that in later versions of gdb
> though.
> 
> - If your code makes use of the C++ STL you can enable a number of
> debugging options.  See
> <http://article.gmane.org/gmane.comp.gnu.mingw.user/19540> for an
> example.  These will certainly slow things down but you get all sorts of
> useful sanity checks in return.
> 
> - Don't forget that you can set the error_start parameter of $CYGWIN to
> gdb or insight and when the fault occurs you will be taken to the
> debugger at the exact point of failure, instead of just being dumped out
> to the prompt with a .stacktrace file written.  See
> <http://cygwin.com/cygwin-ug-net/using-cygwinenv.html> for details.  You
> can also use dumper.exe to get a real core file instead of just the
> .stacktrace.
> 
> - OutputDebugString() and dbgview (from Microsoft nee sysinternals.com)
> make for a very powerful alternative to "a bunch of printf()s".  For one
> thing, it works when there is no console, such as with a GUI app, or
> when there's no stdout; you don't have to fuss with opening a temp file
> for debug output, you can just call OutputDebugString from anywhere at
> any time.  Also, you get timestamps for free without having to code them
> as part of the message.  And you can wrap it with vnsprintf so that it
> has the same interface as printf(), e.g.
> 
> void
> msg (const char *fmt, ...)
> {
>   char buf[2000];
>   va_list args;
>   va_start (args, fmt);
>   vsnprintf (buf, 2000, fmt, args);
>   OutputDebugString (buf);
> }
> 
> I'm pretty sure that insight will also catch these messages, as an
> alternative to dbgview; but it will just display them as a stupid
> messagebox which is quite annoying, so you might want to conditionalize
> your msg() code so that you can disable it when you want to use insight,
> if you have a lot of output.  Checking for an environment variable works
> well here.
> 
> That's about all I can remember off the top of my head.
> 
> Brian
> 

Thanks for your long reply, Brian. Seems to be full of useful tips I 
didn't know of! I'm getting ready to go to Stockholm, Sweden right now 
so I don't have time to investigate these tips in details just now but I 
will certainly re-read this reply and try out your suggestions! And as 
you may have noticed in my reply to Dave, the particular bug in my 
program turned out to be a double delete that I've fixed. Note that I 
write, "particular bug", not "the bug", because I'm sure there are 
plenty more bugs lurking in my code. ;)

- 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/