X-Spam-Check-By: sourceware.org
Message-ID: <461AD324.97CBCE0E@dessent.net>
Date: Mon, 09 Apr 2007 16:58:28 -0700
From: Brian Dessent <brian AT dessent DOT net>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Status of hstrerror() and h_errno in cygwin and one more important    question
References: <evebhg$f38$1 AT sea DOT gmane DOT org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.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

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

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