Wednesday, November 12, 2008

AddVectoredExceptionHandler prevents Purify from working


In all our Windows executables we AddVectoredExceptionHandler so that we can get .dmp files when things crash. However, I recently discovered that doing so preventsPurify from working correctly on Windows. This should probably be expected, and I'm probably not chaining to the next handler correctly, but it's something to watch out for.

Subtopic #1: In all other operating systems, if you want a core dump file, it's very straight-forward; you ulimit -c unlimited, and you get core files. In Windows, you have to write your own Dump file from code that you write. You could depend on Dr. Watson, or Windows Error Reporting, but if you want your own dump file in a place where you or your customers can find it, you have to write it yourself.

Subtopic #2: Fifteen years ago, Purify was the most important development tool you could have. It's still the most important development tool you could have, except that it hasn't really changed in 15 years. I have several friends that are ex-Pure, and they are also dismayed at how it's just not keeping up. For instance:
  • It wasn't until 2004 (or was it 2006?) that you could really use Purify on Linux. Wow.
  • We still can't Purify JNI C code in a Java JVM on Linux. The JVM does magic things that Purify can't handle. Oh well.
  • Purify for Windows doesn't even work on x64.

Tuesday, November 11, 2008

WDK 6001.18001 NDISPROT 5x cancel code bug


I spent some time determining that the sample code for ndisprot that is included in the 6001.18001 WDK has a bug in the IRP cancel code. What's worse is that the bug only exists in the directory labeled 5x, not the directory labeled 60.

For some (at least 2) of the samples in the latest WDK's, they made a clean break from the NDIS 5.x and earlier sample code when they wrote the samples for NDIS 6.0. In the NDIS 6.0 sample they wrote the cancel code according to the pseudo code in MSDN. Unfortunately, they didn't back-port those changes/fixes to the sample code in the 5x directory (sample code intended for NDIS 5.x)

My full description/conversation is here:

http://www.osronline.com/showthread.cfm?link=142677

Thursday, August 14, 2008

Java SSL connection calls InetAddress.getLocalHost


That sounds innocuous, right?
When you call InetAddress.getLocalhost(), a reverse DNS lookup for your hostname is done. In the worst case, you’ve specified a DNS server that isn’t reachable, and so you have to wait for the DNS timeout, which can be quite long, like 30 seconds or 2 minutes. The reason the crypto code in JCE is doing this is for a random seed generator. Seems you could find something else more random than your hostname…
Below I’ve replicated the sample code that I created for this fix, in case it’s of any use to anyone:
I’ve found what I believe is a workaround to this problem, that seems to work against Java6. It works by setting the system property impl.prefix, and using implementations derived from the following classes:
java.net.PlainDatagramSocketImpl
java.net.Inet4AddressImpl
java.net.Inet6AddressImpl
The override implementations of Inet4AddressImpl and Inet6AddressImpl are designed to make sure that InetAddress.getLocalHost() returns an answer without causing any network access. That means that SSL connections, when constructing their random seed that includes the local hostname, will not hang when DNS cannot be reached.
The reason PlainDatagramSocketImpl is overridden is because the system propertyimpl.prefix is also used to construct it; if impl.prefix is not specified, then a prefix of “Plain” is assumed, and thus PlainDatagramSocketImpl is loaded. Therefore we must provide an implementation that with our own matching prefix.
The main class, DefeatGetLocalHost sets the system property impl.prefix to “DefeatGetLocalHost”. This will cause the following classes to be loaded when they are needed:
java.net.DefeatGetLocalHostDatagramSocketImpl
java.net.DefeatGetLocalHostInet4AddressImpl
java.net.DefeatGetLocalHostInet6AddressImpl
The reason that these derived classes are set in the same package, java.net, is because constructors and methods are package protected; therefore placing them in the same package provides the highest level of compatibility.
Also, in order to get our derived classes in package java.net to load in the Java runtime, we have to append the boot classpath. This is done with: -Xbootclasspath/a: after which we specify the directory with our class files.
In the next comment are the source files that I wrote to demonstrate. Compile it and execute DefeatGetLocalHost using -Xbootclasspath/a: to include the overridden classes.
java/net/DefeatGetLocalHostDatagramSocketImpl.java:
package java.net;

class DefeatGetLocalHostDatagramSocketImpl extends PlainDatagramSocketImpl {
}
java/net/DefeatGetLocalHostInet4AddressImpl.java:
package java.net;
import java.io.IOException;

class DefeatGetLocalHostInet4AddressImpl extends Inet4AddressImpl {

    public String getLocalHostName() {
        System.out.println("Using implementation " +
                           this.getClass().getName() + ".getLocalHostName");
        return "localhost";
    }

    public InetAddress[] lookupAllHostAddr(String hostname)
        throws UnknownHostException {

        System.out.println("Using implementation " +
                           this.getClass().getName() + ".lookupAllHostAddr");

        if (hostname.equals("localhost")) {
            return new InetAddress[] {
                InetAddress.getByAddress(new byte[] {
                        (byte)127, (byte)0, (byte)0, (byte)1
                    })
            };
        }

        return super.lookupAllHostAddr(hostname);
    }
}
java/net/DefeatGetLocalHostInet6AddressImpl.java:
package java.net;
import java.io.IOException;

class DefeatGetLocalHostInet6AddressImpl extends Inet6AddressImpl {

    public String getLocalHostName() {
        System.out.println("Using implementation " +
                           this.getClass().getName() + ".getLocalHostName");
        return "localhost";
    }

    public InetAddress[] lookupAllHostAddr(String hostname)
        throws UnknownHostException {

        System.out.println("Using implementation " +
                           this.getClass().getName() + ".lookupAllHostAddr");

        if (hostname.equals("localhost")) {
            return new InetAddress[] {
                InetAddress.getByAddress(new byte[] {
                        (byte)127, (byte)0, (byte)0, (byte)1
                    })
            };
        }

        return super.lookupAllHostAddr(hostname);
    }
}
DefeatGetLocalHost.java:
public class DefeatGetLocalHost {

    public static void main(String[] args) {
        try {
            safeMain(args);
        } catch(Throwable e) {
            e.printStackTrace();
        }
    }

    private static void safeMain(String[] args)
        throws java.net.UnknownHostException, java.net.SocketException {

        System.setProperty("impl.prefix", "DefeatGetLocalHost");

        System.out.println("Getting localhost:");
        System.out.println(java.net.InetAddress.getLocalHost().getHostAddress());

        System.out.println("Creating DatagramSocket:");
        java.net.DatagramSocket dg = new java.net.DatagramSocket();
        dg.close();

        System.out.println("Success");
    }
}

Friday, February 8, 2008

Compiling xemacs 21.5.28 on Ubuntu 7.10

I'm actually now a GNU Emacs user, not an XEmacs user, but in case this is helpful to anyone I've recorded how I figured out how to the get the XEmacs source to compile on Ubuntu 7.10.

The reason I'm no longer an XEmacs user is because it's just not keeping up with GNU Emacs, but more importantly, there is an extremely annoying bug...

Update: It appears that the "Xlib: unexpected async reply" that I refer to above is fixed in Ubuntu 8.04. Too bad I'm now using GNU Emacs...

Wednesday, January 30, 2008

VMware Fusion 1.1 plus OS X 10.5.1 == freeze


Most of the info about this I put in this thread: http://communities.vmware.com/thread/115466

This issue was affecting me quite a bit after upgrading to OS X Leopard VMware Fusion. I helped by collecting the kernel stack traces for the VMware engineer Ben Gertzfield. From there he reproduced the problem and determined that this is a bug in the OS X kernel. Apple Radar bug 5679432 was filed, and fixed in 10.5.3.

Monday, January 14, 2008

Common NSIS coding mistake with macros


Read this forum entry I wrote about what could be a common NSIS coding mistake with macros. For instance, this code:
IfErrors 0 +2
!insertmacro LogProgressMessage '"There was an error..."'
will likely cause the error "Installer corrupted: invalid opcode" at runtime. Instead of using +2, you should use a label.

Tuesday, January 1, 2008

log4j can swallow InterruptedException via InterruptedIOException

Just filed a bug against log4j; it can swallow InterruptedException delivered to a thread that uses logging. This is because it catches IOException and ignores it, but IOException can also be InterruptedIOException, which can be generated on some platforms when a thread is interrupted.

Update: As of 8/14/2008, the log4j developer Curt Arnold has bug 44157 fixed, and the current plan is to ship the fix with log4j 1.2.16.