Bug 191523 - FileDialog crashes JVM
Summary: FileDialog crashes JVM
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Steve Northover CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-07 13:20 EDT by Ed Snible CLA
Modified: 2019-09-06 16:05 EDT (History)
3 users (show)

See Also:


Attachments
Java class demonstrating the problem (1.42 KB, text/plain)
2007-06-07 13:22 EDT, Ed Snible CLA
no flags Details
Snippet that crashes the JVM on Linux GTK (2.04 KB, text/x-java)
2010-06-17 17:06 EDT, Syed Atif CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Snible CLA 2007-06-07 13:20:54 EDT
The JVM crashes if given a shell with an active PopupDialog.

A maintainer reported on #188317 that this is because PopupDialogs dispose themselves when they are deactivated.  I'm attaching code that shows a PopupDialog successfully creating a ElementListSelectionDialog, but crashing the JVM when attempting to create a FileDialog.
Comment 1 Ed Snible CLA 2007-06-07 13:22:40 EDT
Created attachment 70533 [details]
Java class demonstrating the problem

This class demonstrates the problem.  Have a plugin or RCP app do "PopupDialog pop = new BugPopupDialog(new Shell()); pop.open();" to test.
Comment 2 Kevin Barnes CLA 2007-06-07 13:59:47 EDT
SWT only test case: 
	public static void main(String[] args) {
		final Display display = new Display();
		final Shell shell = new Shell(display);

		Button buttonBrowse = new Button(shell, SWT.PUSH); //$NON-NLS-1$
		buttonBrowse.setBounds(10, 10, 100, 40);
		buttonBrowse.setText("Browse...");
		buttonBrowse.addSelectionListener(new SelectionAdapter() {
			public void widgetSelected(SelectionEvent e) {
				FileDialog fsd = new FileDialog(shell, SWT.SINGLE);
				String fname = fsd.open();
				System.out.println(fname);
			}
		});
		shell.addListener(SWT.Deactivate, new Listener() {
			public void handleEvent(Event event) {
				shell.dispose();
			}
		});

		shell.setBounds(200, 200, 300, 300);
		shell.open();
		while (!shell.isDisposed()) {
			if (!display.readAndDispatch())
				display.sleep();
		}
		display.dispose();
	}
Comment 3 Syed Atif CLA 2010-06-17 16:57:37 EDT
I have a similar scenario which crashes the JVM on Linux GTK. Please see attached SWT-only code that reproduces the problem on Linux GTK.

I open a shell that has styles SWT.ON_TOP | SWT.RESIZE applied to it and attach a shell listener listener to this shell. I then call close() and dispose() on the shell when I receive a deactivate event.

On Windows, this works fine: when the user deactivates the shell, the shell is closed and disposed of.

On Linux GTK, this crashes the JVM. On further investigation, the GTK shell code calls OS.gdk_window_invalidate_rect** right after sending the Deactivate event to listeners. However, since the shell has already been disposed of, this crashes the JVM.

A workaround is to call dispose inside an asyncExec. But that is a hack which we are uncomfortable with. Perhaps the fix could be to check if shell has been disposed of before invalidating the shell?




** line 753 of Shell#filterProc(..) under the FocusOut switch case.
Comment 4 Syed Atif CLA 2010-06-17 17:06:41 EDT
Created attachment 172161 [details]
Snippet that crashes the JVM on Linux GTK

Instructions:
1. Run the snippet
2. Click on the button
3. Click on the borderless shell that popups up to give it focus.
4. Click on the original parent shell with the button, to deactivate the child shell.

JVM crashes.
Comment 5 Eclipse Webmaster CLA 2019-09-06 16:05:52 EDT
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.