Status of hstrerror() and h_errno in cygwin and one more important question
Tue Apr 10 07:15:00 GMT 2007
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
> 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
> - 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
> - 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.
> msg (const char *fmt, ...)
> char buf;
> 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.
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. ;)
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin