sporadic issue : Search results : Incomplete search results are shown
Bug type : Sporadic Eclipse version : 2023-09 (4.29) Build id: I20230802-1800 OS : Linux
Steps to reproduce:
- Import the attached project. p60.zip
- Open File Search then search for text
some - Check the search results in
Search View. Mostly for the first time results are complete. Clear Allusing "Search View" toolbar and hitRefreshnext to it. Try this 4-5 times quickly.- It can be reproduced only by clicking
Refreshin theSearch Viewtool bar couple of time instantly. - Now observe the results in step 4/5 sometimes some results are missing. Please refer the attached images.
In development environment when I lauch a 'run-time' in debug mode this is very frequent. Even the first time search results are incomplete.
Below is the screenshot of the first serach result from run-time debug.
Some viewer update problem? I see the total matches count is consistent...
I’ve seen this problem too on Windows but it’s hard to reproduce. I thought maybe it was related to multi thread search.
I thought maybe it was related to multi thread search.
That could be - It's not deterministic which thread handles which file . i'd be happy to help if someone finds the bug. may be somewhere near org.eclipse.search.internal.ui.text.FileSearchQuery.TextSearchResultCollector.endReporting()
I get it frequently on large PHP projects. Possibly the search seems to miss listing hits in files I have open editors for.
If I pull the search results back from the "Show previous searches" history menu at the top right of the search pane, the listing shows correctly (without re-running the search).
I see it reported over here too: https://bugs.eclipse.org/bugs/show_bug.cgi?id=581802 Daniil Terentev there says:
I can add that if you change view from tree to list and then back to tree display of search results becomes correct.
My set up... Version: 2023-12 (4.30.0) Build id: 20231201-2043 Windows 10
How has this bug not been fixed? This is absolutely crucial. Gonna stop using eclipse if this doesn't get fixed in time.
This also isn't rare, i can reliably reproduce this with a project of ours, where it excludes atleast 1 (sometimes as much as 4!) of 12 files for over 90% of a specific search.
eclipse is open source. you can contribute a fix please.
eclipse is open source. you can contribute a fix please.
Bad response, imho. This isn't about any contribution or something, this is about prioritization inside the project.
And in any case, what i can do is offer you to tell me (or really anyone else who has commented here and in the bugzilla report) what we can provide so you can actually fix it.
inside the project.
you are talking about humans that volunteer for their specific needs. There is no public funded team that has any responsibility or priorities..
eclipse is open source. you can contribute a fix please.
Bad response, imho. This isn't about any contribution or something, this is about prioritization inside the project.
I have the impression that you are lacking some understanding of how open-source development works. Prioritization is basically made by what contributors consider most important. And in case of an open-source projects that is usually up to them or the people paying them for doing the work (which is usually some company they work for). That said, option how you can achieve this bug being fixed should become clear to you:
- you can do it yourself
- you pay someone to do so (I guess you have not paid for using Eclipse so far, have you?)
- you convince someone (in any other way than paying him or her) else to make contribution
I have the impression that you are lacking some understanding of how open-source development works.
Na, but you misread my comment. Also we are repeating the same tired open source discussion here again, but whatever.
Prioritization is basically made by what contributors consider most important.
And usually these contributors have an interest in the project they contribute to, and i would assume that extends to it being usable. Atleast in my mind that means critical bugs being worked on. I also assume that people who regularly contribute talk to each other in some form or another, organize about what can and should be done. If this doesn't happen for eclipse, well, that's probably not great.
I am out. The comments are completely unrelated to this issue and I will not participate in any discussion repeatedly blaming all the great, professional, and honorable Eclipse contributors for being unable to properly prioritize and communicate.
@wlfbck If you want more success in getting support from open-source contributors, I suggest you only add constructive technical details that would help fixing the issue as comments (the 2nd part of your initial comment can be helpful for instance). Other things like rudely forcing your expectation regarding how people who don't owe you anything should do their work to serve you better are -as you can see here- most often counter-productive for everyone, including yourself. So maybe a restart from scratch would help: if you can reproduce with high frequency, would you be able to share some details such as the project content, whether it can be reproduced as frequently for some colleagues on various OSs and so on?
I would love to fix it, if I could make it happen with some regularity. It's super annoying! And I always think "One of these days I'm going to make a bad mistake because I'll make a bad assumption that I've seen every match when in fact I haven't."
@wlfbck If you want more success in getting support from open-source contributors, I suggest you only add constructive technical details that would help fixing the issue as comments (the 2nd part of your initial comment can be helpful for instance). Other things like rudely forcing your expectation regarding how people who don't owe you anything should do their work to serve you better are -as you can see here- most often counter-productive for everyone, including yourself.
Agree actually. Goes both ways though.
So maybe a restart from scratch would help: if you can reproduce with high frequency, would you be able to share some details such as the project content, whether it can be reproduced as frequently for some colleagues on various OSs and so on?
Standard maven (so Java) project, yes my colleague can reproduce this as well (just called and tried with him). Both on Win11-23H2. We are doing a "File Search", no checkbox checked, with scope "Enclosing Project". What we are searching for is simply a word which occurs in a couple of .properties files, as can be seen in the screenshot.
Can you verify whether the issue also occurs when using the list view (instead of the tree view) for showing the results?
We once found that the issue does not seem to occur when switching to the list view (but I do not find any documentation of that anymore).
If @merks suggested earlier, that could be related to thread safety, can those who reproduce with higher probability mention how many CPU cores they have and which Java version they're using? On Fedora 41 with "Intel® Core™ i7-8665U × 8" and using Java 23.0.1 shipped as part of Fedora, I cannot reproduce using the example project and steps from the initial comment (even using debug mode).
Can you verify whether the issue also occurs when using the list view (instead of the tree view) for showing the results?
We once found that the issue does not seem to occur when switching to the list view (but I do not find any documentation of that anymore).
Switching to list view (or indeed any way to "refresh" the view of the current search) makes it show the full results, but has to be done for each and every search. Simply using the list view always does not work, just tried. It does appear way less frequent with the list view though.
If @merks suggested earlier, that could be related to thread safety, can those who reproduce with higher probability mention how many CPU cores they have and which Java version they're using? On Fedora 41 with "Intel® Core™ i7-8665U × 8" and using Java 23.0.1 shipped as part of Fedora, I cannot reproduce using the example project and steps from the initial comment (even using debug mode).
My colleague and i are both using a Dell Latitude 5540 which has a i7-1370P (6+8 cores, 20threads according to intel ark). I'm reproducing this with Eclipse Adoptium JDK 21.0.4. Unfortunately i cannot share the project, since it is proprietary. I can run any kind of logging or debugging though if wanted.
Sometimes the summary tells me different information. Here I've filtered to the deepest match.
Here I wonder that it's showing 37 of 42 which to me means it filtered 5 matches...
Sometimes the tree will be off too:
I can't get into a state where the content itself is off, just the summaries, though it's a bit of an eye-chart...
