Summary: | VM crash ? when browser widget is being used | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Tom Hofmann <eclipse> | ||||
Component: | SWT | Assignee: | Christophe Cornu <christophe.cornu+eclipse> | ||||
Status: | RESOLVED FIXED | QA Contact: | |||||
Severity: | blocker | ||||||
Priority: | P1 | CC: | daniel_megert, douglas.pollock | ||||
Version: | 3.1 | ||||||
Target Milestone: | --- | ||||||
Hardware: | PC | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Tom Hofmann
2005-02-17 04:33:25 EST
I see this too and can reproduce it on our buildmachine by adding the Javadoc view, setting the focus to the Package Explorer (or Navigator) and then shutting down. When I now start the workspace it crashes (after few seconds). I had to delete .metadata/.plugins/org.eclipse.ui.workbench/workbench.xml to rescue the workspace. There's no VM dump. Attaching the dialog. Created attachment 18048 [details]
The error dialog when the VM dumps
To get you going, you can disable the Browser widget on Linux with: csh setenv MOZILLA_FIVE_HOME EMPTY eclipse The SWT Browser will not find Mozilla as a result. Daniel: I then got a dialog saying the text widget would be used instead when starting Eclipse. Popping up this dialog does not seem the right thing to do since Eclipse hasn't come up at this point. Maybe you should silently use the Text widget instead. The Welcome page does not warn users it's using the non Browser page in that case. I was able to reproduce the test case in comment 1. Raising priority. side note: the javadoc should not specify the meta charset in the Browser.setText(String). The content is Unicode based because it is inside a java String. The meta charset must not be set as a result. But this is not the cause of the crashes here. Need to check if that's a recent regression or not. Also occurs on Linux Motif. Appears to be caused by the new Mozilla profile support bug 58103. At the moment I'm pretty sure it is, but there is a certain random part to the crash and that will need to be confirmed by Tom and Daniel. Rolling back changes from bug 58103 on Linux GTK and Linux Motif in HEAD. Since it's too late to reach anybody, the decision for a rebuild will have to wait tomorrow morning. Tom/Daniel: since you are six hours ahead of us in Zurich, maybe you can take org.eclipse.swt from HEAD and org.eclipse.swt.gtk - and verify self-hosting Eclipse is now stable with the fix. Leaving PR open for now - however HEAD contains the workaround. >side note: the javadoc should not specify the meta charset in the >Browser.setText(String). Thanks for the hint - filed bug 85801 to track this. Re comment 3: please file a bug report if you think the current behavior is a bug. I think it's a good thing to give first time users a hint that the Browser widget isn't correctly installed and that there's normally more to see in the Javadoc view. You can check the box and you won't see the dialog again. >Tom/Daniel: since you are six hours ahead of us in Zurich, maybe you can take
> org.eclipse.swt from HEAD and org.eclipse.swt.gtk - and verify
> self-hosting Eclipse is now stable with the fix.
Sure Christophe.
To self-host I'd have to create the SWT plug-in and SWT-GTK fragment which was
not straight-forward for me. I was able to build the swt.jar but building the
GTK libs (via ) failed with compile errors - I assume because my system wasn't
setup correctly for that job.
Next time, it would be good to provide the built plug-in and fragment as they
appear in the drop.
Anyway, I did the following to successfully verify the fix:
1. created a small target workspace that exposed the problem
2. replaced SWT together with the GTK fragment with source and built it
3. ran the same target workspace many times, clicked around and could not
reproduce the problem
Looks good!
>Since it's too late to reach anybody, the decision for a rebuild will have to
>wait tomorrow morning.
Because users who switch to 3.1 M5 and start their workspace might immediately
get a VM dump this is a NO GO for me.
Thanks for the try. Another way was to: - download org.eclipse.swt from HEAD into your workspace - download org.eclipse.swt.gtk from HEAD into your workspace - go to the resource perspective and rename the file org.eclipse.swt/.classpath_gtk to org.eclipse.swt/.classpath - Eclipse rebuilds org.eclipse.swt - self-host and try to crash That's exactly what I did. Guess I didn't express myself good enough then ;-) SWT map file updated and M5 rebuild requested. In comment 5, should read (correct bug number): Appears to be caused by the new Mozilla profile support bug 80033 v20050218 marking as fixed. To be verified in upcoming M5 rebuild. assigning to myself Reopen. On one Linux box, problem still occurs with Mozilla 1.7.5 but not with Mozilla 1.4. Daniel/Tom: what is your Linux distribution and Mozilla build? Christophe, the one that we refer to is 1.6 Ok. The current result of our testing is that - we crash with Mozilla 1.7.5 from Mozilla.org even in old Eclipse builds (M3/M4). Not a regression. - bug 80033 caused all versions of Mozilla to crash (1.4 to 1.7.5) - removing the code from bug 80033 removed the regression (1.4 to 1.6 work - 1.7.3 from Mandrake and Fedora Core 3 work). We still crash with Mozilla 1.7.5 from Mozilla.org. Post M5 - need to check 1.7.5 crash and bug 80033 Sounds good. Closing. 1.7.5 issue captured in bug 84053 |