drag-n-drop from native CDE/Motif to java VM causes ""Segmentation Fault" if dnd is performed right after a dnd within java VM using the following test. The same test works fine on WINDOWS. The problem can be reprodued with jdk1.2 beta4 build I by the following steps:
1. on Solaris 2.6 (or 2.5.1), launch test TestButton
2. DnD from button "Drag ME" to "Drop on Me"
3. OK. Now dnd some text from CDE to the target button
4. resulted in:

text/plain; class=java.io.InputStream; charset=unicode
[Target] dragEnter
[Target] dragOver
[Target] dragOver
[Target] dragExit
FATAL ERROR in native method: Wrong method ID used to invoke a Java method
        at sun.awt.motif.MToolkit.run(Native Method)
        at java.lang.Thread.run(Compiled Code)
SIGABRT 6* abort (generated by abort(3) routine)
    si_signo [6]: SIGABRT 6* abort (generated by abort(3) routine)
    si_errno [0]: Error 0
    si_code [-1]: SI_LWP [pid: 20928, uid: 37013]
        stackpointer=EAAC0C30

Full thread dump:
    "Screen Updater" (TID:0xebcb05a8, sys_thread_t:0x34d418, state:R) prio=4
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Compiled Code)
        at sun.awt.ScreenUpdater.nextEntry(Compiled Code)
        at sun.awt.ScreenUpdater.run(Compiled Code)
    "AWT-Motif" (TID:0xebcad230, sys_thread_t:0x241fb8, state:R) prio=5 *current thread*
        at sun.awt.motif.MToolkit.run(Native Method)
        at java.lang.Thread.run(Compiled Code)
    "AWT-Input" (TID:0xebcad258, sys_thread_t:0x23f9e8, state:CW) prio=5
        at java.lang.Object.wait(Native Method)
        at sun.awt.motif.InputThread.run(Native Method)
    "AWT-EventQueue-0" (TID:0xebcad2f8, sys_thread_t:0x221c68, 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:0xebc983a0, sys_thread_t:0x64478, 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:128)
    "Reference Handler" (TID:0xebc98430, sys_thread_t:0x61700, 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:209)
    "Signal dispatcher" (TID:0xebc982e8, sys_thread_t:0x36ad0, state:CW) prio=10
    "Thread-0" (TID:0xebcb02a0, sys_thread_t:0x294d8, state:CW) prio=5
Monitor Cache Dump:
    sun.awt.motif.MToolkit@EBCAD150/EBD63690: owner "AWT-Motif" (0x241fb8, 1 entry)
        Waiting to be notified:
            "AWT-Input" (0x23f9e8)
    sun.awt.ScreenUpdater@EBCB05A8/EBD690D0: owner "Screen Updater" (0x34d418, 1 entry)
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>
    Dynamic loading lock: <unowned>
    Monitor IO lock: <unowned>
    User signal monitor: <unowned>
        Waiting to be notified:
            "Signal dispatcher" (0x36ad0)
    Child death monitor: <unowned>
    I/O monitor: <unowned>
    Alarm monitor: <unowned>
        Waiting to be notified:
        Internal clock thread (ef7a0dd8)
    Thread queue lock: <unowned>
        Waiting to be notified:
            "Thread-0" (0x294d8)
    Monitor registry: owner "AWT-Motif" (0x241fb8, 1 entry)
Segmentation Fault

Here is the test:
 
/home/tinasu/ws/Drag-n-Drop/SmallTests/TestButton

The problem is only repeatable on Tina's machine, which leads me to believe
that the problem is caused by some inherrent interaction between the native
Xlib/Motif libraries and the AWT implementation that is not present in my
debugging environment.

The actual problem is in awt_XmDnD.c: flush_cache where it would seem that
the _cache structure still contains some information that it invalid when
the attempt to clean it up occurs. In particular the bug occurs when validating
the targets object reference prior to releasing it.

I am unable to debug this cause of this further at this time.

larry.cable@Eng 1998-06-18

The problem was in the cache flushing algorithm on the Drop Target side.
When a drop operation occurred within the same JVM the drop target cache was
not flushed.

Subsequent operations failed to filter out duplicate target ATOM's from the
list of targets, and thus a Java object was 'freed' twice. The fix ensures
that the cache is flushed always.
larry.cable@Eng 1998-06-26