Summary: | COM.DoDragDrop crashes JVM with EXCEPTION_ACCESS_VIOLATION | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Thomas Butz <tbutz> | ||||
Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> | ||||
Status: | NEW --- | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | lshanmug, nikita, niraj.modi, paul-eclipse | ||||
Version: | 4.16 | ||||||
Target Milestone: | --- | ||||||
Hardware: | PC | ||||||
OS: | Windows 10 | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Thomas Butz
2020-06-17 04:37:31 EDT
The regression seems to be introduced by 4.13 Can you please provide any steps/snippet to reproduce to the problem? I'm able to trigger the bug in our application by using frequent drag&drop operations. But i fear that i'm not able to break it down to a simple and reproducible test case as our application is rather complex. Any tips how to gather more information? I don't often deal with crash dumps so I might miss something but if I read it correctly you are starting another drag operation while the first is still active. The full stacktrace contains two j org.eclipse.swt.internal.ole.win32.COM.DoDragDrop(JJI[I)I+0 j org.eclipse.swt.dnd.DragSource.drag(Lorg/eclipse/swt/widgets/Event;)V+469 entries. I'm not yet sure how this is even possible. However, from what I can tell DragSource was never really meant to be re-entrant and especially not after bug 549643. On your side you might be able to prevent those nested drag&drop operation. On SWT side we might be able to make drag() re-entrant safe or prevent a nested drag by deferring any dragDetect event while a drag is active. |