When a normal (checked) networking exception should be thrown by the java.net
native code for JDK 1.2 on win32, instead a bizarre looking (unchecked) error
gets thrown instead. Following is a typical example:

java.lang.NoClassDefFoundError: M_recv in socket input stream readJVM_recv in socket input stream readJVM_recv in socket input stream readJVM_recv in socket input stream readJVM_recv in socket input stream readJVM_recv in socket input stream readJVM_recv in socket input stream readJVM_recv in socket input stream readJVM_recv in socket input stream readJVM_readJVM_recv in socket input stream readJVM_recv in socket input stream read
        at java.net.SocketInputStream.socketRead(Native Method)


The problem is caused by the misuse of C string handling introduced by
SCCS delta 1.9 of src/win32/native/java/net/net_util_md.c, in the NET_ThrowNew
function. This delta attempted to preserve the "reason" string handed in the
second paramter by concatenating it to the error string deemed appropriate by
the switch statement on the win32 error code. But this was done with a
call to strcat() like this:

       msg = strcat("Connection reset by peer: ", reason);

strcat() does NOT dynamically allocate more memory to hold its result; the
second parameter is written directly in memory after the end of the first
parameter. There is never a good reason to use a string literal as the
first parameter to strcat(); this will just write overwrite the memory after
the first literal, which is very likely to be more string literals, which
aren't meant to be written over... My guess as to what's causing the exact
behavior of the bug is that the C compiler has put the string name of the
exception in the string literal table right after the string literal to be
concatenated to, and thus the "reason" string overwrites the name of the
class to look up. Upon multiple calls, this string gets continually
added to, and hence it is asking to look up a class name that looks like a
whole bunch of error messages strung togther...