Bugzilla – Full Text Bug Listing
| Summary: | [implementation] Deadlock in ASTProvider after computer resumes | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Dag Rende <dag.rende> | ||||||||
| Component: | Text | Assignee: | Dani Megert <daniel_megert> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||
| Severity: | major | ||||||||||
| Priority: | P3 | CC: | daniel_megert, deepakazad, irbull, markus.kell.r, stephan.herrmann | ||||||||
| Version: | 3.6 | ||||||||||
| Target Milestone: | 3.8 M4 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Dag Rende
Created attachment 198761 [details]
java thread dump when freezed
*** This bug has been marked as a duplicate of bug 160192 *** (In reply to comment #2) > > *** This bug has been marked as a duplicate of bug 160192 *** No this is not a duplicate of that bug. My eclipse DOES NOT freeze when I use Ctrl-C. Your stacktrace is the same as in bug 160192 (ClipboardOperationAction. doCutCopyWithImportsOperation etc.). Bug 160192 also doesn't happen every time. Dag, in comment 3 did you want to say "My eclipse *** DOES *** freeze"? Also, you indicate that you can reproduce the problem. Is suspend/resume an important part of the scenario? Not a dup of bug 160192. (In reply to comment #5) > Dag, in comment 3 did you want to say "My eclipse *** DOES *** freeze"? > > Also, you indicate that you can reproduce the problem. Is suspend/resume an > important part of the scenario? No it does NOT freeze. I have never had any problems with copy by ctrl-c in indigo on ubuntu 11.04. (In reply to comment #7) > (In reply to comment #5) > > Dag, in comment 3 did you want to say "My eclipse *** DOES *** freeze"? > > > > Also, you indicate that you can reproduce the problem. Is suspend/resume an > > important part of the scenario? > > No it does NOT freeze. I have never had any problems with copy by ctrl-c in > indigo on ubuntu 11.04. OK, you say that it does not freeze when using Ctrl+C, but the stack trace from comment 1 says otherwise. Now, what are the steps to make it freeze then? Can you reproduce those? If so, can you attach another dump? Created attachment 199299 [details]
eclipse-hang-3.log
java thread dump for the reproducable freeze
Created attachment 199300 [details]
ConvertEncoding.java
java code used for the reproducable freeze
Now I have a reproducable case with minimal configuration.
1. download and unpack eclipse-java-indigo-linux-gtk.tar.gz
2. start the eclipse from a shell with eclipse >eclipse-hang-3.log
3. create the java project ConvertEncoding
4. create a java class ConvertEncoding and enter some code.
5. suspend and resume
6. do a simple edit of the code (not using ctrl-c), resulting in a freze.
7. check pid of the eclipse process
8. do kill -QUIT <pid>
*To reproduce the freeze, repeat steps 2, 5 and 6.
I attach the zipped workspace containing the code.
The edit I did to get the freeze was:
on line 34 (above the line starting with "pane.add(new JLabel(" "), "),
- I typed the five chars "pane." to get the method list
- I backspaced five times to remove the typed chars
- On the line above I selected "new JButton("Browse")" and typed ctrl-1 but now I didn't see the list of choices as I got the freeze.
dag@tp:~$ java -version
java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.2) (6b22-1.10.2-0ubuntu1~11.04.1)
OpenJDK Server VM (build 20.0-b11, mixed mode)
Eclipse build:
Version: Indigo Release
Build id: 20110615-0604
I attach eclipse-hang-3.log and the java class ConvertEncoding.java i used in the example.
Dag, are you able to reproduce without step 5: suspend and resume? Deepak, any chance to reproduce it on your Linux box? *** Bug 351665 has been marked as a duplicate of this bug. *** (In reply to comment #12) > Dag, are you able to reproduce without step 5: suspend and resume? No. (In reply to bug 351665 comment #6) > Stephan, could it be that you get this after your computer returned from sleep? Wow, using the pristine Eclipse SDK 3.7 I yesterday installed for this purpose, and as my first actions in Eclipse after resume I did: browse, hover, copy, paste, save => frozen. The debug trace shows the same pattern as attached in bug 351665. The connection to suspend-resume would also explain why I started getting this some days ago: before that I was working on a desktop with no suspend support. These days I'm working on my notebook and freequently use suspend. FWIW I did check VM-dependency: problem occurred on openjdk versions 1.6 and 1.7. Should I test more VMs? Thanks for the update guys! I guess this is an old bug which already existed before 3.7 I'm sorry, I should have said that this happened also in 3.6.2. (In reply to comment #17) > Thanks for the update guys! > > I guess this is an old bug which already existed before 3.7 (In reply to comment #17) > I guess this is an old bug which already existed before 3.7 It may be possible to reproduce with older Eclipse, but I've been working with Eclipse on Ubuntu with suspend/resume for many years and I can't remember seeing this sort of freeze before this summer. My guess is that some external change in the system (JDK, or even OS) has some impact on the timing when waking up after resume. From the logs I'd say it should theoretically be possible on any OS and without suspend but by very cleverly placing some breakpoints. FWIW, in bug 351665 I reported the last words from logging before freeze: main - ASTProvider > about to reconcile: ExceptionHandlingFlowContext.java main - ASTProvider > caching AST: null for: ExceptionHandlingFlowContext.java Worker-94 - ASTProvider > waiting for AST for: ExceptionHandlingFlowContext.java Text Viewer Hover Presenter - ASTProvider > waiting for AST for: ExceptionHandlingFlowContext.java main - ASTProvider > waiting for AST for: ExceptionHandlingFlowContext.java (complete logs in attachment 199392 [details]) To be investigated during M4. This lock has never occurred since I upgraded to ubuntu 11.10. (In reply to comment #21) > This lock has never occurred since I upgraded to ubuntu 11.10. Thanks Dag for reporting! |