Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4070685

net exceptions in win32 cause java.lang.NoClassDefFoundError

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      1.2alpha2
    • CPU:
      x86, sparc
    • OS:
      solaris_2.5
    • Verification:
      Not verified

      Description

      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...

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              busersunw Btplusnull User (Inactive)
              Reporter:
              peterjones Peter Jones
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: