Community
Participate
Working Groups
This is repeatable, at least it is for me. Right click on a Java project and select export. Select General/Archive File, then click Next. When the Export dialog comes up, click the Browse button. Eclipse vanishes in a puff of smoke. No error message, nothing. It just stops and disappears instantly. This is with 3.3RC1 It does not have to be a Java project. It does the same thing for a C project. I just happened to encounter it 1st with a Java project.
Do you have a .log file or a core dump?
Created attachment 68141 [details] .log file I stopped Eclipse, deleted the .log file, started Eclipse and immediately caused the crash.
Created attachment 68146 [details] JVM core dump? This appears to be relevant to the crash.
Created attachment 68150 [details] Another JVM core dump I updated my JVM to 1.6 Update 1, no change in the crash behavior. Note that I am running as an Admninistrator, not a Standard User.
Here is the relevant code in the core dump j org.eclipse.swt.internal.win32.OS.GetSaveFileNameW(Lorg/eclipse/swt/internal/win32/OPENFILENAME;)Z+0 j org.eclipse.swt.internal.win32.OS.GetSaveFileName(Lorg/eclipse/swt/internal/win32/OPENFILENAME;)Z+7 j org.eclipse.swt.widgets.FileDialog.open()Ljava/lang/String;+726 Which version of Vista are you using with which virtual machine? Vista Ultimate with J9 is working for me.
I am on Vista Business and the JVM is Sun's J2SE6
Created attachment 68176 [details] SWT only example Here is an SWT only example. Joseph can you try this on RC1?
The ControlExample does not crash on my machine.
Tod's example code does not crash on my machine.
The steps don't crash for me either. Can you confirm that the FileDialog works in other applications like Notepad? CAR and Kevin, were there other crashes in the FileDialog on XP related to 3rd party software running?
I ran your FileDialogTest and it did not crash. It worked perfectly. ???
Looking at the dll's that are loaded, I see one called TCPSPYLSP.DLL. This appears to beong to a program called TCP Spy, which appears to be some sort of spyware detector? (just at a quick google glance <g>) Would you be able to temporarily disable/unload this program and try running again? (or maybe just temporarily rename the dll, if you don't want to unload). The reason I am asking you to try this is because we had a problem a while back with an application called Synergy from Telelogic. If you are curious, see bug 87798. Telelogic had a bug in their code that crashed other people's file browsers, and eclipse was hitting it. Perhaps you have tripped over something similar.
I mean, try repeating your steps in the Export dialog with the TCP Spy turned off.
This is weird. I have TCPSpy (from www.westbrooksoftware.com, very usefull!) installed on my machine but I have not used it for several days. My TaskManager does not show it to be active. I cannot see it under Applications, Processes or Services. Where did you see it?
I see it in the JVM core dump. I'll remove the dll (or rename it temporarily), reboot, and try again.
Created attachment 68196 [details] Another JVM dump I had to uninstall TCPSpy. I also, just for good measure, uninstalled VMWare version 6 as it installs virtual network devices and I thought that just maybe they were part of the problem. It still failed. I attached the JVM dump.
Jospeph, are you running Eclipse on a network drive or locally?
Completely local. (I work out of my house.)
Re comment 16, thanks for trying. Sorry about the extra work - I hope you can easily get TCP Spy installed again. It was worth a try, though, given that it is the type of thing that can go wrong.
No problem. I well understand how difficult (and maybe even impossible) some bugs are to find. I have since found an odd mix of failure and success trying to export using other types. If I try to export to Java/Javadoc, the browse button works. But if I try Java/Jar it fails. Every time!
Now this should be interesting. I just went back to 3.3M7 and it does not fail! So, at least for me, this is brand new with RC1.
*** Bug 188327 has been marked as a duplicate of this bug. ***
Re comment 21: The SWT FileDialog class has not changed since September 2006, and it's pretty much a stand-alone class. Tod, has the method of calling the FileDialog in the "Export to Java/Jar" case changed recently (between M7 and RC1)? Joe, please note: the FileDialog class did change *after* RC1. Are you using RC1 when you see the failure, or perhaps did you take SWT from HEAD since then?
I am using plain jane stock RC1.
I can't speak for export to Jar - it is provided by JDT
works for me too. What VM are you running ? In the wizard is the text field next to 'To archive file:' empty or do you have something in there ?
I am using Sun's J2SE6 (build 1.6.0_01-b06) I have tried it both ways, with and without any text in the file name box. It still fails consistently for me either way. I just now tried export to General/File System and it did NOT fail.
i am using the same VM on Vista Ultimate with no problem. Jospeh does this happen with a 1.5 VM?
I'll give J2SE5 a try. It will take a while.
Joe is using Vista Business and Sun's J2SE6 VM. Kevin or Felipe or Steve - does any of you have Vista Business edition? If so, can you get the 1.6 VM and try Exporting to Java/Jar and see if you crash?
I'm running Ultimate with the 1.6 VM and I have never crashed.
This IS interesting. It does NOT break with Sun's J2SE5. So it looks like something is a bit hinky with J2SE6??
In case it is relevant, I am running the 32-bit Vista Business on a Core 2 Duo E6600 CPU with 4GB of ram.
The next thing to do is check the C code to see whether we are passing garbage to GetOpenFileNameW(). The obvious thing that comes to mind is that the OPENFILENAME struct is stack allocated. How about we hack the C code to malloc() and zero it and do a bunch of prints? Does that crash? How about hacking the C code to not use it at all (ie. do everything in C)? Does that crash? Since it does not crash on your machine, Kevin will look into building you DLL to try tomorrow.
There hasn't been any changes to 'Export to JAR' recently (some changes unrelated to the UI were done in 3.3 M6).
Created attachment 68682 [details] replacement dll Please replace your dll with the attached dll and see if you still crash. Only change is to move memory from stack to heap before opening the save file dialog This dll's implementation of GetSaveFileNameW: #ifndef NO_GetSaveFileNameW JNIEXPORT jboolean JNICALL OS_NATIVE(GetSaveFileNameW) (JNIEnv *env, jclass that, jobject arg0) { OPENFILENAME _arg0, *lparg0=NULL; jboolean rc = 0; HANDLE hHeap; LPVOID pt; OS_NATIVE_ENTER(env, that, GetSaveFileNameW_FUNC); if (arg0) if ((lparg0 = getOPENFILENAMEFields(env, arg0, &_arg0)) == NULL) goto fail; hHeap = GetProcessHeap (); pt = HeapAlloc (hHeap, HEAP_ZERO_MEMORY, sizeof(OPENFILENAME)); MoveMemory (pt, &_arg0, sizeof(OPENFILENAME)); //rc = (jboolean)GetSaveFileNameW((LPOPENFILENAMEW)lparg0); rc = (jboolean)GetSaveFileNameW((LPOPENFILENAMEW)pt); MoveMemory (&_arg0, pt, sizeof(OPENFILENAME)); HeapFree (hHeap, 0, pt); fail: if (arg0 && lparg0) setOPENFILENAMEFields(env, arg0, lparg0); OS_NATIVE_EXIT(env, that, GetSaveFileNameW_FUNC); return rc; } #endif
I found that dll in \configuration\org.eclipse.osgi\bundles\124\1\.cp Is that right? Anyway, I replaced it with the one that was attached and, sorry to say, it still failed.
Created attachment 68685 [details] JVM dump Here is the JVM dump from that last test with the alternate swt-win32-3344.dll
Felipe, let's make a version of GetSaveFileNameW() that does not use the argument at all and just makes the operating system call. We need to put a print or something to ensure that Joseph is running it. NOTE: The simple code that Tod provided works, right? We need to determine what flags are being passed to Windows in the case that fails and change Tod's simple code to use them. Does that crash?
Created attachment 68810 [details] new dll try this one. if the dll is gets loaded propertly you should see a dummy messge box comming up right before the save file dialog. Here is the code: #ifndef NO_GetSaveFileNameW JNIEXPORT jboolean JNICALL OS_NATIVE(GetSaveFileNameW) (JNIEnv *env, jclass that, jobject arg0) { OPENFILENAMEW Ofn={0}; TCHAR szFile[MAX_PATH]=""; MessageBoxW(NULL, L"test dll on", L"test dll on", MB_OK | MB_ICONINFORMATION); Ofn.lStructSize = sizeof (OPENFILENAMEW); Ofn.lpstrFile= szFile; Ofn.nMaxFile = sizeof(szFile)/ sizeof(*szFile); Ofn.Flags = OFN_SHOWHELP | OFN_OVERWRITEPROMPT; return GetSaveFileNameW((LPOPENFILENAMEW)&Ofn); // OPENFILENAME _arg0, *lparg0=NULL; // jboolean rc = 0; // OS_NATIVE_ENTER(env, that, GetSaveFileNameW_FUNC); // if (arg0) if ((lparg0 = getOPENFILENAMEFields(env, arg0, &_arg0)) == NULL) goto fail; // rc = (jboolean)GetSaveFileNameW((LPOPENFILENAMEW)lparg0); //fail: // if (arg0 && lparg0) setOPENFILENAMEFields(env, arg0, lparg0); // OS_NATIVE_EXIT(env, that, GetSaveFileNameW_FUNC); // return rc; } #endif note: i forced the all the calls to be unicode. note: the return of the dialog will be ignored. We just want to know if it crashes or not.
This is painfully strange. It crashed and I did not see the test dialog. I am pretty sure that Eclipse is using the dll file that you sent me because I cannot delete it while Eclipse is running. Does this mean it is crashing before it gets to the C code?
1) Get SWT from HEAD (see http://www.eclipse.org/swt/cvs.php). 2) Debug Eclipse from within Eclipse. 3) Put a break point in FileDialog.open() 4) Step right up to the call to GetSaveFileName() 5) Do you crash when you step into it?
It will take me a while to do this.
Created attachment 68822 [details] screenshot If you run my dll you will see the little dialog as shown the screenshot.
Running with your dll, I am not seeing the test dialog. Very odd. Also very odd, I loaded SWT into my Eclipse workspace and ran it as an 'Eclipse Application' using the workspace SWT instead of the installation SWT. It did not fail! I realize that this is making no sense. As a developer I have faced bugs like this myself and I understand how frustrating they can be when you cannot reproduce them and the evidence is slippery and contradictory. I can't spend much time on this for the next few days as I have a project to complete. I'll just have to work around the problem.
> Running with your dll, I am not seeing the test dialog. Very odd. Then you are not testing our code (ie. you are running with the old code) and this means that any conclusions we came to using the DLL that Kevin sent you are suspect. Do you agree? Please go inside the plugin folder and replace the DLL inside the SWT jar. NOTE: Make a copy first! Then run Eclipse with -clean. You could also try deleting (or renaming) the DLL in the OSGi folder to make sure that Eclipse is picking up our hacked DLL from the JAR.
Aha! I did not know that I had to replace the dll inside the jar. Please see comment #37, I guess that was not the right one?
(In reply to comment #47) > Aha! I did not know that I had to replace the dll inside the jar. > Please see comment #37, I guess that was not the right one? I'm not sure what OSGi does, I think the first time you run they extract the DLL from the jar and they place in a folder for some reason (?). The name of the folder (the numerical part) is different from instalation to instalation. Try to delete the DLL in the OSGi folder and run with -clean, that should force them to load the DLL from the Jar.
I tested the special dll from 5/25 by putting it in the SWT project in my Eclipse workspace. I ran Eclipse from Eclipse and I did see the special little message box. And it did not fail! But when I try to insert that dll in the Eclipse installation, I do not see the special dialog and it still fails. I am still not sure that I am doing it correctly. Here are the steps I took. (three times, same result!) 1. Locate org.eclipse.swt.win32.win32.x86_3.3.0.v3344.jar in the plugins directory and save a copy of it. 2. In the above named jar, replace swt-win32-3344.dll with the special one. I used the jar utility for this. 3. Locate the copy of this dll under .../configuration/org.eclipse.osgi/... and delete it. 4. Launch Eclipse with the -clean option. 5. Run the test, it still failed. I ran thru these steps three times, slowly. Still no special message box and still failing. very very odd. Looking at the JVM dump it looks like somehow Eclipse may still be using the original dll. So I may still not be getting the test right. BTW I am now testing this with RC2
Pascal, I compiled a new swt dll and I want Joseph to run eclipse with it, please read note #49. Somehow eclipse never loads the dll I gave to him. Are we missing something here ? DO you know why eclipse doesn't pick the new dll ?
Felipe, I don't think you need to get eclipse to load the dll any more. Joe figured out how to get eclipse-in-eclipse to load it (see the beginning of comment 49), so you can debug this problem more easily if you go that route. Joe, maybe you can try getting the dll that Kevin supplied in comment 36 on 05/24. (It looks like the attachment is "obsolete" but it isn't). Do the same "replace the dll in the swt project in your workspace" trick, and then run eclipse from eclipse. Does this fail? Felipe, please note that if you make a new dll after this, the version number was bumped up to 3345 in the current swt code in HEAD.
I tried the eclipse-in-eclipse route with the dll from 5/25 and it did not fail. I have not been able to get it to fail this way. I have tried it with the original and the testing DLLs and it refuses to fail when running eclipse-in-eclipse. But I have an idea why I was unable to get the special DLL running with normal Eclipse. I am working on it.
Eclipse is really tenacious about its plugins. I was finally able to get the special dll with the test dialog box to run in Eclipse. I saw the test dialog, then it crashed.
Did it crash before the FileDialog appeared? (ie. you got the MessageBox)
Pascal, what could possibly be the difference between running eclipse, and running eclipse in eclipse? Assume that the VM is the same, and the version of every plugin is the same (including swt, which is in the workspace). Joe opens a file dialog in eclipse, and crashes. He opens the same file dialog in eclipse-in-eclipse, and does not crash. The only differences that I can think of are workspace preferences, and perhaps the contents of the 2 workspaces, but I don't think either of those could affect how the File Dialog operates. Joe, did we ever try starting completely from scratch with a fresh download/install of eclipse (into a new location) and a brand-new empty workspace? If that works, you could try importing the projects in your original workspace into the new workspace (File->Import... Existing Projects Into Workspace).
In answer to #54, it crashed immediately after I hit the Ok button on the special test MessageBox.
I'll try a completely fresh install of RC2.
Interesting. A completely virgin install of Eclipse RC2 did not fail. I have a newly created empty workspace and no other plugins except the ones that come with it. I created a Java project and a Test.java file. Then tried to export to General/Archive and it did not fail. Two plugins that I always use are the GEF and the CDT. I'll add them one at a time and see what happens.
Wow. This is really interesting. The C code that you ran in comment 40 does not use any of the JNI arguments at all. Are you running with javaw.exe or java.exe?
I am not specifying. I assume that the launcher uses javaw. I just added the GEF and the CDT and it is not failing yet. I'll add projects one at a time and see what happens.
Holy C**P! I found it. One other thing that is different from launching Eclipse from the OS and launching it from within Eclipse is the command line arguments. I have been in the habit of using this... -vmargs -Xmx768m IT FAILS WITH THIS! IT DOES NOT FAIL WITHOUT IT!!
It seems to fail with any setting of Xmx. I tried 512, 256, 128, 64, all failed. So I changed it to only this... -vmargs -Xmn64m and that failed too! When I remove all vm arguments, it works fine. The VM seems to really dislike being told anything about its heap size.
Nice work, Joe! I am impressed with your patience <grin>. Thanks for sticking with this. Now what... Steve? Shall we close this as "won't fix"?
Joe, can you attach a "java -version" to this bug report?
Myu most recent test were with this... C:\Program Files\Java\jre1.5.0_11\bin>java -version java version "1.5.0_11" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing)
But it also fails with this... C:\Program Files\Java\jre1.6.0_01\bin>java -version java version "1.6.0_01" Java(TM) SE Runtime Environment (build 1.6.0_01-b06) Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)
I'm getting core dumps with FileDialog on XP. I'm testing using a Constellation based on 3.3RC1, but I've had this since at least 3.2. My error only happens when I open a FileDialog with the shell from a PopupDialog.
Created attachment 70520 [details] Java class demonstrating the problem
Unhandled exception Type=Segmentation error vmState=0x00040000 J9Generic_Signal_Number=00000004 ExceptionCode=c0000005 ExceptionAddress=763B53DA ContextFlags=0001003f Handler1=7EFB04E0 Handler2=7F057A80 InaccessibleAddress=00000000 EDI=00000000 ESI=633A5208 EAX=00000000 EBX=00000000 ECX=77D4C458 EDX=00000001 EIP=763B53DA ESP=0006E100 EBP=00000000 Module=C:\WINDOWS\system32\comdlg32.dll Module_base_address=763B0000 Offset_in_DLL=000053da Target=2_30_20070406_12209_lHdSMR (Windows XP 5.1 build 2600 Service Pack 1) CPU=x86 (4 logical CPUs) (0xbff77000 RAM) JVMDUMP006I Processing Dump Event "gpf", detail "" - Please Wait. JVMDUMP007I JVM Requesting System Dump using 'C:\winapps\33rc1\core.20070607.162235.5908.dmp' JVMDUMP010I System Dump written to C:\winapps\33rc1\core.20070607.162235.5908.dmp JVMDUMP007I JVM Requesting Snap Dump using 'C:\winapps\33rc1\Snap0002.20070607.162235.5908.trc' JVMDUMP010I Snap Dump written to C:\winapps\33rc1\Snap0002.20070607.162235.5908.trc JVMDUMP007I JVM Requesting Java Dump using 'C:\winapps\33rc1\javacore.20070607.162235.5908.txt' JVMDUMP010I Java Dump written to C:\winapps\33rc1\javacore.20070607.162235.5908.txt JVMDUMP013I Processed Dump Event "gpf", detail "".
Ed, PopupDialog's dispose themselves when they are deactivated. Since your PopupDialog will be deactivated by the opening of your FileDialog the crash is happening (ie you are disposing the file dialog's parent, while you are creating the file dialog). Please file a new bug report for this.
I'm going to close this as "won't fix" which simply means that we aren't going to try to work around it in swt code. I have also added the following item to the eclipse 3.3 release notes: Opening File Dialog crashes eclipse (Vista only) On Vista, launching eclipse using -vmargs -Xmx[any size] can crash eclipse when the FileDialog is opened. The workaround is to use the default heap size, i.e. do not use the -Xmx VM args. See bug 188317 for details. Thanks again for your patience in tracking this down, Joe!
*** Bug 199684 has been marked as a duplicate of this bug. ***
*** Bug 222408 has been marked as a duplicate of this bug. ***
Created attachment 275039 [details] .log
