Dangerous code, indeed.

Feb-13-2008

Oops, FlightGear won't start after applying the Mac OS X 10.5.2 update. I got some reports from users complaining about FlightGear (fgfs) quits unexpectedly on launch and falls back to GUI.

With a quick trace, the problem happens when "Download Scenery on the fly" option is enabled. So I disabled the option and tried it again to find FlightGear launched with no problems. A log file sent from a user shows that SimGear fails to connect to a udp socket. Why such thing happens? Did Apple change anything about socket implementation? To check this, I wrote a very simple ruby script that connects to terrasync via udp ---- and it worked as expected.

So, the cause IS in FlightGear side, not in Apple side. Tracing back the SimGear code gives me a real cause of this issue:

/*
 * Socket address, internet style.
 */
class netAddress
{
  /* DANGER!!!  This MUST match 'struct sockaddr_in' exactly! */
  short          sin_family;
  unsigned short sin_port;
  unsigned int   sin_addr;
  char           sin_zero [ 8 ] ;

As the comment saiys, it is DANGER since it highly depends on socket implementation. As a matter of fact, Apple implements the sockaddr_in struct in a different way:

struct sockaddr_in {
        __uint8_t       sin_len;
        sa_family_t     sin_family;
        in_port_t       sin_port;
        struct  in_addr sin_addr;
        char            sin_zero[8];            /* XXX bwg2001-004 */
};

sizeof(sockaddr_in) is the same but the member variables are not exactly the same. Especially the first and second members are critical, which caused the problem. So I made an easy-way-out kinda patch to avoid this issue. It seems working find on my Mac.

I'll make a quick tests on other Macs and make an updater package, combined with r154-candidate.