Details

    • Subcomponent:
    • Introduced In Version:
      5.0
    • Resolved In Build:
      b02
    • CPU:
      x86
    • OS:
      linux
    • Verification:
      Not verified

      Description

      FULL PRODUCT VERSION :
      java version "1.6.0-internal"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-internal-furr_01_dec_2005_17_59-b00)
      Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-internal-furr_01_dec_2005_17_59-b00, mixed mode)


      ADDITIONAL OS VERSION INFORMATION :
      SunOS loompa 5.8 Generic_117350-28 sun4u sparc SUNW,Sun-Fire-V210
      Linux bruce 2.6.11.12 #1 SMP Wed Oct 26 14:08:16 EDT 2005 x86_64 GNU/Linux

      A DESCRIPTION OF THE PROBLEM :
      We are currently researching techniques to check type safety for projects
      that use multiple languages via a foreign function interface. We have
      developed a tool for checking programs which use the JNI and have run it
      on mustang build 61 (from Nov 17). We found some code that we believe has
      a bug.

      In the file j2se/src/solaris/native/sun/xawt/XlibWrapper.c, the function
      Java_sun_awt_X11_XlibWrapper_XCreateFontCursor on line 791 may be called from
      two overloaded Java native methods. The Java native method XCreateFontCursor is
      overloaded to accept either an int or a long as its final parameter, however there is only one corresponding C function defined, and it takes an int as its final paramter. As a result, on 64-bit systems where long and int have different sizes, this will incorrectly pull only 32bits of data off of the stack; on big-endian systems, this data will be the higher 32bits
      of the value which will likely have ill effects. The method with the long signature does not appear to be called from anywhere within the mustang code base, so this bug is not currently visible. However, it could easily be triggered in the future updates, so we recommend fixing it.



      REPRODUCIBILITY :
      This bug can be reproduced rarely.

      CUSTOMER SUBMITTED WORKAROUND :
      Since the long version of the Java method does not appear to be used in the mustang code base (and is protected, so external programs can't call it), one fix would be to simply remove this version of the method leaving only the method with an integer as its final parameter.

      If the method is expected to be used in the future, then two different versions of the C function should be defined to handle each method signature. Indeed, the signatures of such functions are already generated during the build in control/build/<platform>/tmp/sun/sun.awt.X11/xawt/CClassHeaders/sun_awt_X11_XlibWrapper.h with the postfix __JI and __JJ (likely from the javah tool).

        Attachments

          Activity

            People

            • Assignee:
              son Oleg Sukhodolsky (Inactive)
              Reporter:
              rmandalasunw Ranjith Mandala (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Imported:
                Indexed: