Summary: | [index] Deadlock when doing Type Hierarchy while updating a large workspace | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Martin Oberhuber <mober.at+eclipse> | ||||||||
Component: | Core | Assignee: | Frederic Fusier <frederic_fusier> | ||||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||||
Severity: | major | ||||||||||
Priority: | P3 | CC: | daniel_megert, frederic_fusier, karenfbutzke, kent_johnson, markus.kell.r, martinae, pzuev, schacher | ||||||||
Version: | 3.3 | ||||||||||
Target Milestone: | 3.3 M7 | ||||||||||
Hardware: | PC | ||||||||||
OS: | Windows XP | ||||||||||
Whiteboard: | |||||||||||
Attachments: |
|
Description
Martin Oberhuber
2007-03-21 10:27:53 EDT
Created attachment 61547 [details]
Full thread dump of the deadlock
PS eclipse.exe runs at 50% CPU on my hyperthreaded machine, so it's taking 100% of one virtual core. The dump doesn't look like a deadlock but the UI being blocked by the indexer still doing work. I waited for more than 30 minutes. Never had an indexer take that long. I also can't see anything special in this dump. It seems the update thread has already ended and the indexer is just working. I'm expecting here that the type hierarchy shows the progress bar in the status bar and it is possible to cancel. I've never seen an indexer taking 30 minutes. Yes, that's strange. Can't do much without more information. Setting to remind. Maybe the indexer ran into a loop? Can you take several thread dumps and see if the stack trace of the indexer job is different in these several dumps or always at the same place (ie. DiskIndex.readStreamChars(DiskIndex.java:853)? Thanks Created attachment 61582 [details]
Portions of .log during the time the deadlock happened
Attached are portions of my .log file for the time when the deadlock happened.
I could not find anything that looked connected to the deadlock.
I did indeed see the progress bar operate in the window trim. It's cancel button reacted to mouse-over and I could press it, but the Workbench did not react.
All UI was totally frozen except for the progress bar and cancel button.
Not a single menu item would react in any way.
I'm afraid I can't since this was a one-time thing which I don't think I can reproduce. Since I needed my workspace I had to kill the workbench... next time, I'm going to do more than one thread dump. Sorry. That's expected from looking at the stack trace as the main thread is waiting for the TH. Reopen as we got this issue while starting the monster workspace used for bug 146577... Problem is effectively in DiskIndex.readStreamChars(FileInputStream) method. In the case of monster workspace, while reading a disk index file, we got following numbers while entering the while (i<length) loop: this.bufferEnd = 2048 this.bufferIndex = 2046 So, charsInBuffer is equals to i as ((this.bufferEnd - this.bufferIndex) / 3) = 0! Then we drop in an infinite loop.. :-( It sounds like the test of the second loop is invalid: while (i < charsInBuffer) { charsInBuffer is only an estimated size to see if the rest of the buffer can contain all the word remaining characters, it should not be used to test to loop inside the buffer. It appears that in this case we loop infinitely but on other cases, we surely miss several characters at the end of the buffer. I guess we pass all Search tests due to the fact that our disk index files are small (we do not use the real complete rt.jar file in our tests) Forget my previous comment.... readStreamBuffer(FileInputStream) is shifting the unread characters at the end of the buffer to the beginning => this should be OK... I'll continue to investigate this failure tomorrow morning using monster workspace on David's box where the infinite loop was always reproducible. I also reproduced it using the monster workspace available on our Numbat drive in Workspaces root folder. Here's the scenario: 1) Unzip the monster workspace 2) Start an eclipse session on this wksp 3) Wait for the end of Java Tooling Initialization 4) Open type 5) Enter 'a' => after a while of searching indexes, CPU heats at 100% and never stops. It was not possible to quit eclipse, you have to kill the session! DiskIndex loops on readStreamChars because in this case, the stream parameter is null when call stack is: - DiskIndex.readStreamChars(FileInputStream) line: 851 - DiskIndex.readChunk(String[], FileInputStream, int, int) line: 681 - DiskIndex.readDocumentName(int) line: 725 - EntryResult.getDocumentNames(Index) line: 53 - ... Then, readStreamBuffer(FileInputStream) is never called, so charsInBuffer never changes and loop runs infinitely... Created attachment 63027 [details]
Proposed patch
Released for 3.3 M7 in HEAD stream. *** Bug 181475 has been marked as a duplicate of this bug. *** *** Bug 181459 has been marked as a duplicate of this bug. *** *** Bug 181459 has been marked as a duplicate of this bug. *** Verified for 3.3M7 for I20070427-0010 *** Bug 187861 has been marked as a duplicate of this bug. *** |