Bug ID: JDK-4180145 Incorrect JNI field id used to access DataFlavor.atom in Solaris DnD code

JDK-4180145 : Incorrect JNI field id used to access DataFlavor.atom in Solaris DnD code

Type: Bug
Component: client-libs
Sub-Component: java.awt
Affected Version:
1.0_beta1,1.0_early_access,1.2.0,1.2.2 1.0_beta1,1.0_early_access,1.2.0,1.2.2

Priority: P3
Status: Resolved
Resolution: Fixed
OS: generic,solaris_2.5.1,solaris_2.6
CPU: generic,sparc

Submitted: 1998-10-09
Updated: 1999-02-03
Resolved: 1999-02-03

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
1.2.2 1.2.2Fixed

Related Reports

Duplicate :	JDK-4226166 - HotSpot VM error when copying and pasting in swing.
Duplicate :	JDK-4251406 - FATAL ERROR in native method: Wrong field ID passed to JNI
Duplicate :	JDK-4202340 - java_g dumps core/SEGVIOL on swing tests
Duplicate :	JDK-4212413 - JTextPane crashes HotSparc VM
Duplicate :	JDK-4207446 - native method registerTargetForFlavor uses a bad JNI fieldID
Duplicate :	JDK-4228055 - FATAL ERROR in native method: Wrong field ID passed to JNI
Relates :	JDK-4208070 - Fatal: Bug in native code: jfieldID class must match object

Description

Run the regression test test/java/awt/Clipboard/ClipRWTest using java_g.
e.g. java_g ClipRWTest

The following error will appear:

FATAL ERROR in native method: Wrong field ID passed to JNI
        at sun.awt.motif.X11Selection.registerTargetForFlavor(Native Method)
        at sun.awt.motif.X11Selection.<clinit>(X11Selection.java:49)
        at sun.awt.motif.X11Clipboard.<init>(Compiled Code)
        at sun.awt.motif.MToolkit.getSystemClipboard(Compiled Code)
        at ClipFrame.<init>(Compiled Code)
        at ClipRWTest.runTest(Compiled Code)
        at ClipRWTest.main(Compiled Code)
SIGABRT   6*   abort (generated by abort(3) routine)
    si_signo [6]: SIGABRT   6*   abort (generated by abort(3) routine)

*** panic: "../../../../../src/solaris/hpi/green_threads/src/mutex_md.c", line 244: assertion failure


*** panic: "../../../../../src/solaris/hpi/green_threads/src/mutex_md.c", line 244: assertion failure


*** panic: "../../../../../src/solaris/hpi/green_threads/src/mutex_md.c", line 252: assertion failure


*** panic: "../../../../../src/solaris/hpi/green_threads/src/mutex_md.c", line 252: assertion failure

    si_errno [0]: Error 0
    si_code [0]: SI_USER [pid: 18514, uid: 74587]
        stackpointer=efffd398

*** panic: "../../../../../src/solaris/hpi/green_threads/src/mutex_md.c", line 244: assertion failure


*** panic: "../../../../../src/solaris/hpi/green_threads/src/mutex_md.c", line 252: assertion failure


*** panic: "../../../../../src/solaris/hpi/green_threads/src/mutex_md.c", line 244: assertion failure


*** panic: "../../../../../src/solaris/hpi/green_threads/src/mutex_md.c", line 252: assertion failure


Full thread dump Classic VM (robi:10.08.98-20:35, green threads):
    "AWT-Motif" (TID:0xebc82c18, sys_thread_t:0x235c28, state:CW) prio=5
        at sun.awt.motif.MToolkit.run(Native Method)
        at java.lang.Thread.run(Compiled Code)
    "SunToolkit.PostEventQueue-0" (TID:0xebc82920, sys_thread_t:0x216d30, state:CW) prio=5
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Compiled Code)
        at sun.awt.PostEventQueue.run(Compiled Code)
    "AWT-EventQueue-0" (TID:0xebc82950, sys_thread_t:0x216bf8, state:CW) prio=6
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Compiled Code)
        at java.awt.EventQueue.getNextEvent(Compiled Code)
        at java.awt.EventDispatchThread.run(Compiled Code)
    "Finalizer" (TID:0xebc98328, sys_thread_t:0x5f728, state:CW) prio=8
        at java.lang.Object.wait(Native Method)
        at java.lang.ref.ReferenceQueue.remove(Compiled Code)
        at java.lang.ref.ReferenceQueue.remove(Compiled Code)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:174)
    "Reference Handler" (TID:0xebc983b8, sys_thread_t:0x5cff8, state:CW) prio=10
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Compiled Code)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:114)
    "Signal dispatcher" (TID:0xebc983e8, sys_thread_t:0x541c8, state:CW) prio=5
    "main" (TID:0xebc981e8, sys_thread_t:0x26590, state:R) prio=5
        at sun.awt.motif.X11Selection.registerTargetForFlavor(Native Method)
        at sun.awt.motif.X11Selection.<clinit>(X11Selection.java:49)
        at sun.awt.motif.X11Clipboard.<init>(Compiled Code)
        at sun.awt.motif.MToolkit.getSystemClipboard(Compiled Code)
        at ClipFrame.<init>(Compiled Code)
        at ClipRWTest.runTest(Compiled Code)
        at ClipRWTest.main(Compiled Code)
Monitor Cache Dump:
    sun.awt.PostEventQueue@EBC82920/EBF5AD80: <unowned>
        Waiting to be notified:
            "SunToolkit.PostEventQueue-0" (0x216d30)
    java.awt.EventQueue@EBC826D8/EBF5AA98: <unowned>
        Waiting to be notified:
            "AWT-EventQueue-0" (0x216bf8)
    java.lang.ref.ReferenceQueue$Lock@EBC98340/EBCCE4C0: <unowned>
        Waiting to be notified:
            "Finalizer" (0x5f728)
    java.lang.Class@EBCB9BC0/EBECFDD8: owner "main" (0x26590) 1 entry
    java.lang.ref.Reference$Lock@EBC983C8/EBCCDF58: <unowned>
        Waiting to be notified:
            "Reference Handler" (0x5cff8)
Registered Monitor Dump:
    PCMap lock: <unowned>
    utf8 hash table: <unowned>
    JNI pinning lock: <unowned>
    JNI global reference lock: <unowned>
    BinClass lock: <unowned>
    Class linking lock: <unowned>
    System class loader lock: <unowned>
    Code rewrite lock: <unowned>
    Heap lock: <unowned>
    Monitor cache lock: owner "main" (0x26590) 1 entry
    Dynamic loading lock: <unowned>
    Monitor IO lock: <unowned>
    User signal monitor: <unowned>
        Waiting to be notified:
            "Signal dispatcher" (0x541c8)
    Child death monitor: <unowned>
    I/O monitor: <unowned>
        Waiting to be notified:
            "AWT-Motif" (0x235c28)
    Alarm monitor: <unowned>
        Waiting to be notified:
            <unknown thread> (0x2b880)
    Thread queue lock: owner "main" (0x26590) 1 entry
    Monitor registry: owner "main" (0x26590) 1 entry


*** panic: "../../../../../src/solaris/hpi/green_threads/src/mutex_md.c", line 244: assertion failure


*** panic: "../../../../../src/solaris/hpi/green_threads/src/mutex_md.c", line 252: assertion failure

Abort


Examination of awt_Selection.c shows that the JNI code in registerTargetForFlavor is using the JNI field id for X11Selection.atom to attempt to access DataFlavor.atom. This occurs several places in the code.

I'm not sure what the implications are in the production build.

robi.khan@eng 1998-10-08

Comments

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.2.2 FIXED IN: 1.2.2 INTEGRATED IN: 1.2.2

14-06-2004

SUGGESTED FIX The code changes are limited to ... ${WORKSPACE}/src/solaris/native/sun/awt/awt_Selection.c (Delta 1.26) 127,128d130 < jclass cls; < jfieldID fieldID; 130d131 < 138,139c139 < cls = (*env)->GetObjectClass(env, flavor); < fieldID = (*env)->GetFieldID(env, cls, "atom", "I"); --- > target = (Atom) (*env)->GetIntField(env, flavor, x11SelectionIDs.atom); 141,142d140 < target = (Atom) (*env)->GetIntField(env, flavor, fieldID); < 180,181d177 < jclass cls; < jfieldID fieldID; 232,234d227 < cls = (*env)->GetObjectClass(env, f); < fieldID = (*env)->GetFieldID(env, cls, "atom", "I"); < 236c229 < (Atom) (*env)->GetIntField(env, f, fieldID); --- > (Atom) (*env)->GetIntField(env, f, x11SelectionIDs.atom); 493,494d485 < jclass cls; < jfieldID fieldID; 503d493 < 507a498 > (*env)->SetIntField(env, flavor, x11SelectionIDs.atom, (jint) target); 509,518d499 < // < // Initialize the DataFlavor.atom with the specified target atom. < // < < cls = (*env)->GetObjectClass(env, flavor); < fieldID = (*env)->GetFieldID(env, cls, "atom", "I"); < < (*env)->SetIntField(env, flavor, fieldID, (jint) target); < <

11-06-2004

EVALUATION This is not a drag&drop related problem, so I am re-classifying this. larry.cable@Eng 1998-10-09 The JNI code in registerTargetForFlavor is using the JNI field id for X11Selection.atom to attempt to access DataFlavor.atom. hania.gajewska@Eng 1998-10-09 Because this covers area's in drag n' drop that we were not covering it's priority has been reduced. I am committing it to 1.2.2 and once that weorkspace has been opened its Priority will be brought back to a P3. See Robi's response : Well, the problem is in a bit of code that maps Java DataFlavor's to X11 Target data types. In production builds, the DataFlavor.atom field is not properly set to point to the correct X11 target. This should cause problems when trying to paste from a native app, but it looks like there is a default code path that avoids this. This is somewhat speculative since: - The ClipRWTest test case always works in production mode - In the debugger I can't get past the JNI assertion to actually see what's going on But looking at the code it only supports a text clipboard, and text cut and paste is definitely working. So there is a problem that needs to be fixed, but it doesn't look like it affects the operation of the clipboard in production mode. SwingSet works, the test case works etc. I think the problem would show up if there were support for X11 data types other than just text, but that appears not to be the case. I would definitely get a second opinion from a Motif expert though. Perhaps Amy? - Robi lara.bunni@Eng 1998-10-12 In a few places, there was an attempt to Set/Get the value of DataFlavor.atom using X11Selection.atom as a fieldID. This would not pass the more rigorous JNI field type checking when using java_g or java -Xcheck:jni. I can only surmise that the fieldID in both classes represents the same value. That is the only explanation as to why the production code worked when just using java. I have fixed the bug by specifying the correct fieldID. james.melvin@East 1999-02-01

01-02-1999