Known Bugs in DTN2

Don't force all names to be resolvable at configuration time

2/22/05, Bob Durst

The issue is that if a name in a link configuration command (and possibly a route command) in the dtn.conf file is not resolvable at dtnd initialization time, then the dtnd exits. This seemed to both of us to be inappropriate, particularly in a network that might be prone to intermittent connectivity. Mike discussed separating "validate" and "resolve" actions as a suggested alternative to the current resolve-at-initialization time behavior.

Cygwin bugs

apps cannot talk to daemon sometimes

Apps sometimes fail to contact the daemon over the DTNAPI connection. I've debugged this so far to a missing UDP packet. I don't know where it gets lost.

Update: As of 12-July-2005, the Cygwin port does not appear to suffer this problem anymore. I'll keep watching for it, but for now it is gone.

signals stop after system()

The following problem was fixed by cygwin1.dll version 1.5.18 (released July 2, 2005)

dtncpd exhibits a problem that my Cygwin has in general. After a system() call, it no longer received signals. This simple program shows the problem:

#include <stdio.h>

int main()
{
        printf("sleeping for 5 secs...\n");
        sleep(5);
        system("echo the hostname is: `hostname`");
        printf("sleeping for 5 secs...\n");
        sleep(5);
}

During the first sleep, you can kill it with ctrl-c. During the second one, you cannot. It will exit correctly after the 5 second sleep. (dtncpd will never exit, because it is in a while(1) loop.)

This cygwin bug is fixed as of the snapshot from March 3, 2005. You can get it here, if you really need signals to work: http://cygwin.com/snapshots/

It's likely this bug has other impacts on DTN2, but I don't know of them yet.

Mac OSX Bugs

debug.h incompatibiliy

If you are getting compilation errors like:

/usr/include/gcc/darwin/3.3/c++/bits/stl_uninitialized.h: In function `char*
std::uninitialized_copy(const char*, const char*, char*)':
/usr/include/gcc/darwin/3.3/c++/bits/stl_uninitialized.h:127: error: `
__glibcxx_requires_valid_range' undeclared (first use this function)

and more relating to basic_string.h, you need to update (cvs source), reconfigure, and build again.

The problem is that Apple includes in their gcc distribution some debugging suppor for the standard c++ library, including a header file /usr/include/gcc/darwin/3.3/c++/debug/debug.h.

Because the Mac OS filesystem is case-insensitive, lines of the form #include <debug/debug.h> from the C++ installation accidentally pick up the file oasys/debug/Debug.h from my code.

To fix this, Mike has added a check to the configure script that looks for the above situation, and included a shell script called fix-apple-debug-header.sh that goes through the c++ include files and changes the file named debug.h to apple-debug.h, along with the handful of #include references to it.

This has been fixed as of 3.10.05.

Wiki

Page