Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 341895

Summary: DND actions in AbstractTreeViewer lead to NPE and application freeze [Carbon]
Product: [Eclipse Project] Platform Reporter: <h1055071>
Component: SWTAssignee: Lakshmi P Shanmugam <lshanmug>
Status: VERIFIED FIXED QA Contact:
Severity: major    
Priority: P3 CC: eclipse.felipe, masgui, remy.suen, Silenio_Quarti
Version: 3.6.2Flags: Silenio_Quarti: review+
eclipse.felipe: review+
lshanmug: review? (eclipse.felipe)
Target Milestone: 3.7 RC2   
Hardware: Macintosh   
OS: Mac OS X - Carbon (unsup.)   
Whiteboard:
Attachments:
Description Flags
Stack Trace log
none
snippet to reproduce bug
none
patch none

Description CLA 2011-04-05 08:48:12 EDT
Build Identifier: M20110210-1200

I noticed lately that a big, serious, crashing Eclipse NPE occurs on DND actions in a SWT Tree in the Carbon version of our RCP application. I traced it to one point in AbstractTreeViewer. This wasn't happening before. So I checked if it was happening in Eclipse Carbon version itself. Yes it does.

Reproducible: Always

Steps to Reproduce:
1. In Package Explorer create some simple files and folders in a General Project.
2. DND some files between folders. Try and do this a few times.

Leads to NPE.
Comment 1 CLA 2011-04-05 08:53:56 EDT
Created attachment 192551 [details]
Stack Trace log

Add the Stack trace
Comment 2 CLA 2011-04-05 08:57:30 EDT
I managed a workaround in my RCP application by wrapping the code that handles the Drop event in a Display.asyncExec() thread.

I wonder if this is a regression introduced by an Apple Java update.

NOTE - this is only happening on Mac Carbon, Cocoa is fine.
Comment 3 CLA 2011-04-06 17:34:22 EDT
This problem is occurring in OS X versions 10.6.4 and 10.6.6 and on Java versions 1.6.0_20 and 1.6.0_24.
Comment 4 CLA 2011-04-07 05:14:25 EDT
I have done some testing with different version of the Eclipse Carbon Mac version. It seems that this regression was introduced in version 3.6.1 as it does not occur in version 3.6.0.

Here are the steps to reproduce using Eclipse Mac Carbon SDK 3.6.1 or 3.6.2:

1. Create a General Project "Foo".
2. In Package Explorer, add two folders under the project node, "Folder1" and "Folder2"
3. Create a new text file, "File.txt" in Folder1.
4. In Package Explorer, drag File.txt from Folder1 to Folder2. All will seem to be well...but now try to drag it back again. There will be a freeze. Check the Eclipse error log, you will see a NPE.

Or, put simply, drag and drop is screwed in the Carbon version of Eclipse.

I think it may be something to do with the order of events?
Comment 5 CLA 2011-04-30 04:39:38 EDT
I guess this won't be fixed then.
Comment 6 Silenio Quarti CLA 2011-05-02 10:59:59 EDT
This was caused by the changes for bug#243529.  Lakshmi, please investigate it.
Comment 7 Lakshmi P Shanmugam CLA 2011-05-12 10:00:58 EDT
Created attachment 195498 [details]
snippet to reproduce bug

This happens when the TreeItem is disposed inside DropTargetListener.drop(). After this Tree.getSelectionCount() returns a wrong value and Tree.getSelection() returns items array with null.
I'm investigating this.
Comment 8 Lakshmi P Shanmugam CLA 2011-05-12 15:35:22 EDT
Created attachment 195535 [details]
patch

When a selected TreeItem is disposed, OS.kDataBrowserItemDeselected message is sent to the Tree. But, since the DRAG_STARTED is set in the control's data, we are selecting the disposed item. The DRAG_STARTED in control's data is cleared only when drag finishes.

The patch resets DRAG_STARTED to null in dragSendDataProc() itself. Tested with the example snippet & Package explorer in the IDE. The patch fixes problem for Table too.

Silenio, can you please review?
Comment 9 Lakshmi P Shanmugam CLA 2011-05-16 02:23:43 EDT
Hi Felipe, can you please review for RC2?
Comment 10 Lakshmi P Shanmugam CLA 2011-05-16 13:29:56 EDT
Fixed in HEAD > 20110516.
Thanks Silenio & Felipe!
Comment 11 Lakshmi P Shanmugam CLA 2011-08-24 02:23:23 EDT
*** Bug 329625 has been marked as a duplicate of this bug. ***