Bug 40051

Comment 1 Veronika Irvine 2003-07-16 09:19:52 EDT

This is a very old build of Eclipse.  Can you please retry in something more 
recent?

It is most likely that the application is throwing an exception from within 
one of the drag or drop event notifications.  In more recent builds, all event 
notification in DND is wrapped to catch exceptions.

Comment 2 Scott Pelton 2003-07-17 18:25:30 EDT

how do I get something morre recent to try?
I got the wsdd eval version about 4 weeks ago....isnt this a fairly recent
version of Eclipse?

Comment 3 Scott Pelton 2003-07-22 17:14:49 EDT

I installed latest swt components. Now I dont get the GPF but dnd does not work.
...dragStart() is never fired when running this snippet dnd app:

http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt-home/snippits/snippet78.html.

Comment 4 Veronika Irvine 2003-07-25 08:48:13 EDT

I ran the snippet with 3.0M2 on Win2K and it worked for me.

Are you throwing an exception in any of your event handlers?  Are any 
exceptions generated when you create the drag source or drop target?

Comment 5 Ulrich Küster 2004-12-14 13:53:01 EST

Hi,

Maybe I can add something to the problem. I'm implementing drag'n'drop on a
TreeViewer. Since I want to drag only within the tree I didn't want to care
about object serialization and used a local variable as clipboard and didn't
really make use of the transfer class. I simply used a TextTransfer, implemented
DragSourceListener from scratch and extended ViewerDropAdapter.
Everything works fine.

However, when I started to use my own implementation of the Transfer class to be
able to distinguish between my transfers and external ones I also got an access
violation that immediately quits my Eclipse as soon as I start a drag operation
on my tree.

I'm using Eclipse 3.0.1 and Windows XP Service Pack 2.

The transfer I'm using:

private class SchemaTransfer extends Transfer {
        private final String TYPE_NAME = "sortimenter-schema-editor-transfer";
	private final int TYPE_ID = registerType(TYPE_NAME);
	public TransferData[] getSupportedTypes() {
		TransferData type = new TransferData();
		type.type = TYPE_ID;
		return new TransferData[] {type};
	}
	public boolean isSupportedType(TransferData type) {
		if (type.type == TYPE_ID) {
			return true;
		} else {
			return false;
		}
	}
	protected int[] getTypeIds() {
		return new int[] {TYPE_ID};
	}
	protected String[] getTypeNames() {
		return new String[] {TYPE_NAME};
	}
	protected void javaToNative(Object object, TransferData data) {
		// do nothing
	}
	protected Object nativeToJava(TransferData data) {
		return dndClipboard; // which is my local clipboard variable
	}
}

I enabled drag'n'drop like this:

int operations = DND.DROP_COPY | DND.DROP_MOVE;
Transfer[] transfers = new Transfer[] {new SchemaTransfer()};
treeViewer.addDragSupport(operations, transfers, new      
SchemaDragSourceListener(treeViewer));
treeViewer.addDropSupport(operations, transfers, new
SchemaDropTargetListener(treeViewer));

where SchemaDragSourceListener and SchemaDropTargetListener are my
implementation of DragSourceListener and my extension of ViewerDropAdapter, but
I don't think they are the problem since they work fine as soon as I change the
line:
Transfer[] transfers = new Transfer[] {new SchemaTransfer()};
to:
Transfer[] transfers = new Transfer[] {TextTransfer.getInstance()};

If you need any further information please contact me. The problem reproduces
quite well.

Below is the exception stack.

regards,
Uli


An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x332A8EC
Function=[Unknown.]
Library=C:\Programme\Eclipse\plugins\org.eclipse.swt.win32_3.0.1\os\win32\x86\swt-win32-3063.dll

NOTE: We are unable to locate the function name symbol for the error
      just occurred. Please refer to release documentation for possible
      reason and solutions.


Current Java thread:
	at org.eclipse.swt.internal.ole.win32.COM.MoveMemory(Native Method)
	at org.eclipse.swt.dnd.OleEnumFORMATETC.Next(OleEnumFORMATETC.java:94)
	at org.eclipse.swt.dnd.OleEnumFORMATETC.access$1(OleEnumFORMATETC.java:80)
	at org.eclipse.swt.dnd.OleEnumFORMATETC$2.method3(OleEnumFORMATETC.java:45)
	at org.eclipse.swt.internal.ole.win32.COMObject.callback3(COMObject.java:88)
	at org.eclipse.swt.internal.ole.win32.COM.DoDragDrop(Native Method)
	at org.eclipse.swt.dnd.DragSource.drag(DragSource.java:277)
	at org.eclipse.swt.dnd.DragSource.access$0(DragSource.java:263)
	at org.eclipse.swt.dnd.DragSource$1.handleEvent(DragSource.java:157)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:796)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:2772)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2431)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1377)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1348)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:254)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:141)
	at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:96)
	at
org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:335)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:273)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:129)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at org.eclipse.core.launcher.Main.basicRun(Main.java:185)
	at org.eclipse.core.launcher.Main.run(Main.java:704)
	at org.eclipse.core.launcher.Main.main(Main.java:688)

Dynamic libraries:
0x00400000 - 0x0040B000 	C:\j2sdk1.4.2_05\bin\javaw.exe
0x7C910000 - 0x7C9C7000 	C:\WINDOWS2\system32\ntdll.dll
0x7C800000 - 0x7C906000 	C:\WINDOWS2\system32\kernel32.dll
0x77DA0000 - 0x77E4A000 	C:\WINDOWS2\system32\ADVAPI32.dll
0x77E50000 - 0x77EE1000 	C:\WINDOWS2\system32\RPCRT4.dll
0x77D10000 - 0x77DA0000 	C:\WINDOWS2\system32\USER32.dll
0x77EF0000 - 0x77F36000 	C:\WINDOWS2\system32\GDI32.dll
0x77BE0000 - 0x77C38000 	C:\WINDOWS2\system32\MSVCRT.dll
0x08000000 - 0x08139000 	C:\j2sdk1.4.2_05\jre\bin\client\jvm.dll
0x76AF0000 - 0x76B1E000 	C:\WINDOWS2\system32\WINMM.dll
0x10000000 - 0x10007000 	C:\j2sdk1.4.2_05\jre\bin\hpi.dll
0x00830000 - 0x0083E000 	C:\j2sdk1.4.2_05\jre\bin\verify.dll
0x00840000 - 0x00859000 	C:\j2sdk1.4.2_05\jre\bin\java.dll
0x00860000 - 0x0086D000 	C:\j2sdk1.4.2_05\jre\bin\zip.dll
0x02EE0000 - 0x02EEF000 	C:\j2sdk1.4.2_05\jre\bin\net.dll
0x71A10000 - 0x71A27000 	C:\WINDOWS2\system32\WS2_32.dll
0x71A00000 - 0x71A08000 	C:\WINDOWS2\system32\WS2HELP.dll
0x02EF0000 - 0x02EF8000 	C:\j2sdk1.4.2_05\jre\bin\nio.dll
0x03300000 - 0x0334E000 
C:\Programme\Eclipse\plugins\org.eclipse.swt.win32_3.0.1\os\win32\x86\swt-win32-3063.dll
0x774B0000 - 0x775EC000 	C:\WINDOWS2\system32\ole32.dll
0x5D450000 - 0x5D4E7000 	C:\WINDOWS2\system32\COMCTL32.dll
0x76350000 - 0x7639A000 	C:\WINDOWS2\system32\comdlg32.dll
0x77F40000 - 0x77FB6000 	C:\WINDOWS2\system32\SHLWAPI.dll
0x7C9D0000 - 0x7D1EE000 	C:\WINDOWS2\system32\SHELL32.dll
0x770F0000 - 0x7717C000 	C:\WINDOWS2\system32\OLEAUT32.dll
0x76330000 - 0x7634D000 	C:\WINDOWS2\system32\IMM32.dll
0x75790000 - 0x757FB000 	C:\WINDOWS2\system32\USP10.dll
0x773A0000 - 0x774A2000 
C:\WINDOWS2\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\comctl32.dll
0x5B0F0000 - 0x5B128000 	C:\WINDOWS2\system32\uxtheme.dll
0x746A0000 - 0x746EB000 	C:\WINDOWS2\system32\MSCTF.dll
0x63000000 - 0x63014000 	C:\WINDOWS2\system32\SynTPFcs.dll
0x77BD0000 - 0x77BD8000 	C:\WINDOWS2\system32\VERSION.dll
0x03980000 - 0x03988000 
C:\Programme\Eclipse\plugins\org.eclipse.core.resources.win32_3.0.0\os\win32\x86\core_2_1_0b.dll
0x74C00000 - 0x74C2C000 	C:\WINDOWS2\system32\oleacc.dll
0x76020000 - 0x76085000 	C:\WINDOWS2\system32\MSVCP60.dll
0x20000000 - 0x202D9000 	C:\WINDOWS2\system32\xpsp2res.dll
0x719B0000 - 0x719F0000 	C:\WINDOWS2\System32\mswsock.dll
0x76EE0000 - 0x76F07000 	C:\WINDOWS2\system32\DNSAPI.dll
0x76F70000 - 0x76F78000 	C:\WINDOWS2\System32\winrnr.dll
0x76F20000 - 0x76F4D000 	C:\WINDOWS2\system32\WLDAP32.dll
0x76F80000 - 0x76F86000 	C:\WINDOWS2\system32\rasadhlp.dll
0x66710000 - 0x66769000 	C:\WINDOWS2\system32\hnetcfg.dll
0x719F0000 - 0x719F8000 	C:\WINDOWS2\System32\wshtcpip.dll
0x76320000 - 0x76325000 	C:\WINDOWS2\system32\msimg32.dll
0x76C50000 - 0x76C78000 	C:\WINDOWS2\system32\imagehlp.dll
0x59DD0000 - 0x59E71000 	C:\WINDOWS2\system32\DBGHELP.dll
0x76BB0000 - 0x76BBB000 	C:\WINDOWS2\system32\PSAPI.DLL

Heap at VM Abort:
Heap
 def new generation   total 1152K, used 529K [0x10010000, 0x10150000, 0x104f0000)
  eden space 1024K,  45% used [0x10010000, 0x10085af0, 0x10110000)
  from space 128K,  46% used [0x10110000, 0x1011eba0, 0x10130000)
  to   space 128K,   0% used [0x10130000, 0x10130000, 0x10150000)
 tenured generation   total 14564K, used 8938K [0x104f0000, 0x11329000, 0x14010000)
   the space 14564K,  61% used [0x104f0000, 0x10daabb8, 0x10daac00, 0x11329000)
 compacting perm gen  total 17408K, used 17204K [0x14010000, 0x15110000, 0x18010000)
   the space 17408K,  98% used [0x14010000, 0x150dd1d8, 0x150dd200, 0x15110000)

Local Time = Tue Dec 14 19:40:43 2004
Elapsed Time = 51
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode)
#
# An error report file has been saved as hs_err_pid3420.log.
# Please refer to the file for further information.
#

Comment 6 Veronika Irvine 2004-12-14 14:25:34 EST

Ulrich,

1) The field TransferData.type is platform specific and may not exist on all 
platforms.  Therefore your implementation only works on some platforms:

/**
* The type is a unique identifier of a system format or user defined format.
* (Warning: This field is platform dependent)
*/
public int type;

2) Your implementation of javaToNative has to do something.  On all platforms, 
the TransferData has some field (platform dependant) that signals whether the 
transfer operation was successful.  The value is set to "failed" by default 
and your implementation must set the field to "succeeded" after successfully 
translating the data to the native form.

3) In public boolean isSupportedType(TransferData type) it is possible 
that "type" is null.  Therefore you are throwing a null pointer exception.  It 
is most likely this that is causing the GP you are seeing.

Please refer to MyTransfer for an example of a platform independant 
implementation of a Transfer subclass:

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets/src/org/eclip
se/swt/snippets/Snippet79.java?rev=HEAD&content-type=text/vnd.viewcvs-markup

Comment 7 Ulrich Küster 2004-12-14 19:15:37 EST

Thank you very much vor your fast response!

I realize that I probably should use a subclass of ByteArrayTransfer instead of
extending Transfer class.
However, I don't understand why and how an error in my code can cause an access
violation that immediately shuts down Eclipse.

I did understand, that my implementation doesn't work on all platforms. I also
did change my implementation of javaToNative to set the result field and I
changed my implementation of isSupportedType(TransferData type) to simply return
true in any case. Therefore it can't possibly throw a NPE anymore.
But nevertheless I still experience the access violation.

Not to be misunderstood: I will change my implementation to use TextTransfer
which already worked fine or I will try a subclass of ByteArrayTransfer but I
still think an error in any extension of Transfer (escpecially my simple dummy
one) should not cause an access violation.

My code has changed to:

private class SchemaTransfer extends Transfer {

	private final String TYPE_NAME = "sortimenter-schema-editor-transfer";
	private final int TYPE_ID = registerType(TYPE_NAME);

	public TransferData[] getSupportedTypes() {
		TransferData type = new TransferData();
		type.type = TYPE_ID;
		return new TransferData[] {type};
	}
	public boolean isSupportedType(TransferData type) {
		// dummy implementation
		return true;
	}
	protected int[] getTypeIds() {
		return new int[] {TYPE_ID};
	}
	protected String[] getTypeNames() {
		return new String[] {TYPE_NAME};
	}
	protected void javaToNative(Object object, TransferData data) {
		data.result = 1;
	}
	protected Object nativeToJava(TransferData data) {
		return dndClipboard; // my local clipboard variable
	}
}

Comment 8 Veronika Irvine 2004-12-15 10:48:22 EST

The Transfer class should only be subclassed by people extrememly familiar 
with native data transfers.  It is not sufficient in javaToNative to say that 
the data has been converted succcessfully.  There is a contract and by saying 
that the data has been converted successfully, you are indicating that you 
have allocated global memory that points to the data and this is available for 
the operating system to transfer.  It also means that all fields in 
TransferData have been correctly filled in.  In your implementation, no memory 
is allocated so when MoveMemory is called, it fails.

Even though you are doing a local transfer, something has to be transmitted 
through the operating system since you are using the OS data transfer 
mechanism.  Below is an example which subclasses ByteArrayTransfer correctly 
for a local transfer.  NOTE: Since this is a local transfer only, you must 
also ensure that your type name is unique bewteen applications.


public class MyTypeInternalTransfer extends ByteArrayTransfer {
	static MyType myInternalData;
	static final MyTypeInternalTransfer instance = new 
MyTypeInternalTransfer();
	static final String TYPE_NAME 
= "MyTypeInternalTransfer"+System.currentTimeMillis();
	static final int TYPE_ID = Transfer.registerType(TYPE_NAME);

public static Transfer getInstance () {
	return instance;
}
private MyTypeInternalTransfer () {
}
boolean checkMyType(Object object) {
	if (object == null || !(object instanceof MyType)) return false;
	MyType myType = (MyType)object;
	if (myType.firstName == null || 
		myType.firstName.length() == 0 ||
		myType.lastName == null ||
		myType.lastName.length() == 0) return false;
	return true;
}
protected String[] getTypeNames(){
	return new String[]{TYPE_NAME};
}
protected int[] getTypeIds(){
	return new int[] {TYPE_ID};
}
public void javaToNative (Object object, TransferData transferData) {
	if (!checkMyType(object) || !isSupportedType(transferData)) {
		return; //DND.error(DND.ERROR_INVALID_DATA); // throw 
exception in 3.1 but in 3.0
	}
	myInternalData = (MyType) object;
	byte[] buffer = TYPE_NAME.getBytes();
	super.javaToNative(buffer, transferData);	
}
public Object nativeToJava(TransferData transferData){	
	if (isSupportedType(transferData)) {
		byte[] buffer = (byte[])super.nativeToJava(transferData);
		if (buffer == null) return null;
		String string = new String(buffer);
		if (string.equals(TYPE_NAME)) {
			return myInternalData;
		}
	}
	return null;
}
protected boolean validate(Object object) {
	return checkMyType(object);
}
}

Comment 9 Leo Ufimtsev 2017-08-03 12:30:35 EDT

This is a one-off bulk update. (The last one in the triage migration).

Moving bugs from swt-triaged@eclipse to platform-swt-inbox@eclipse.org and adding "triaged" keyword as per new triage process:
https://wiki.eclipse.org/SWT/Devel/Triage

See Bug 518478 for details.

Tag for notification/mail filters:
@TriageBulkUpdate

Comment 10 Eclipse Genie 2019-12-23 08:15:11 EST

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.

Comment 11 Scott Pelton 2019-12-23 10:22:40 EST

I have no additional comments as I have been away from this for some time now.