Summary: | Use virtual table/tree for File search | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Stefan Wöhrer <mail> | ||||
Component: | Search | Assignee: | Platform-Search-Inbox <platform-search-inbox> | ||||
Status: | ASSIGNED --- | QA Contact: | |||||
Severity: | enhancement | ||||||
Priority: | P5 | CC: | daniel_megert, eclipse.felipe, remy.suen | ||||
Version: | 3.5.2 | ||||||
Target Milestone: | --- | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Stefan Wöhrer
2010-11-18 06:50:55 EST
(In reply to comment #0) > 9. Stop search while still in progres (red square button in "Search" view > freezes up to about 10 seconds, then crashes completely (shuts down and all > recently made changes are gone) Please get a thread dump while Eclipse is stuck for those ten seconds. http://wiki.eclipse.org/index.php/How_to_report_a_deadlock Created attachment 183381 [details]
A threaddump while eclipse is "frozen"
if i try creating a heapdump with the option "Enable heapdump on OOME" this bug does not occur :(
Does the problem occur with 3.6.1? http://download.eclipse.org/eclipse/downloads/drops/R-3.6.1-201009090800/index.php It sounds like file search could use a configurable limit on search results (stop after first 1000 results, or something like that). We use a l(In reply to comment #4) > It sounds like file search could use a configurable limit on search results > (stop after first 1000 results, or something like that). Search can handle tons of results (I just tried with over 200'000) but if the user then really asks to expand all the elements then of course this uses quite some memory. In my case it took less than a minute and all elements were created without a crash with only 500MB of memory. We could investigate to switch to virtual tree/table but given that even the 200'000 case works with all elements expanded doesn't seem to justify the effort. Moving to SWT to investigate why it crashes. Bug 266296 reports a similar issue. In the case eclipse was frozen the thread was busy creating/rendering items. The case where it crashed, it was becase it was out of memory* (application had already created too many widgets). The only solution I see here to use VIRTUAL. * 'BadAlloc (insufficient resources for operation)' is not necessarily RAM memory that run out, it could be too many windows, colormaps, graphics contexts, or whatever x resource. Move back if you find the crash was not caused by creating too many resource. But note that we can not do anything for out of memory (or insufficient resources) type of errors. 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. |