Community
Participate
Working Groups
Using Eclipse 3.4 it is very easy to crash the platform when doing a search. For example, if you have a large project or workspace and do a search across all files in the workspace it is likely you will get an OutOfMemory error error. Since this is an easy problem to hit with search, it would seem like the search capability should be aware of low memory situations and prompt the user to stop the search before a critical failure occurs. In addition to the IDE, this is also a problem in RCP applications using the search capabilities.
Please provide an exact test case. I work with a large (now what is large?) workspace for years and never had an OOME. Also, about which search are you talking (text, Java, c++, ...)?
Our specific use case involves our product. Our product loads very large non-relational databases into the workspace. The user, perhaps not a programmer, but an end user can then attempt to search the database. So, if in the file search box the user enters * for the search term and * for the file name, the system will search for a while and then crash with an OOME. In the IDE you can do this using the same search term. For a large workspace, I usually create a new General > Project, enter a name, and then change the default location to a location where I have lots of file (e.g. c:\Program Files) on Windows. So the issue is not such a big deal in the IDE because developers will better understand the implications of doing a search like this. However, end users that are not developers could be surprised by this.
But what search are we talking about? Is the database somehow mounted as resources? Where does the OME occur?
The search is run from the "File Search" tab that is opened after clicking on the search icon. The database is viewed through a special navigator. The contents of the database displayed in the navigator using the virtual file system capabilities. The short stack trace is below. I'll attach the larger log file to this bug. Caused by: java.lang.OutOfMemoryError at org.eclipse.search.ui.text.AbstractTextSearchResult.getMatches(Unknown Source) at org.eclipse.search.internal.ui.text.LineElement.getNumberOfMatches(Unknown Source) at org.eclipse.search.internal.ui.text.FileTreeContentProvider.elementsChanged(Unknown Source) at org.eclipse.search.internal.ui.text.FileSearchPage.elementsChanged(Unknown Source) at org.eclipse.search.ui.text.AbstractTextSearchViewPage.runBatchedUpdates(Unknown Source) at org.eclipse.search.ui.text.AbstractTextSearchViewPage.access$1(Unknown Source) at org.eclipse.search.ui.text.AbstractTextSearchViewPage$UpdateUIJob.runInUIThread(Unknown Source) at org.eclipse.ui.progress.UIJob$1.run(Unknown Source) at org.eclipse.swt.widgets.RunnableLock.run(Unknown Source) ... 31 more
Created attachment 113454 [details] Full log showing error
Pierre, your attachment seems corrupt.
There is a style sheet reference in the log xml file. Looks like the viewer/browser is trying to load that. I'll remove the style sheet and reattach. You can also save as and open in a text editor.
Created attachment 113456 [details] Full log showing error without stylesheet
See also bug 143224.
Any updates on this bug? We this be addressed in 3.4.2 or 3.5?
>Any updates on this bug? We this be addressed in 3.4.2 or 3.5? There's currently no time/resource for this.
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.
