exception while searching
Apache NetBeans version
Apache NetBeans 23
What happened
I have a multimodule project. Using Netbeans Find method on specific module with e.g. text "TEST" i find results. Using the find globally or with scope Open Projects I got less results. First I thought, I do not understand what scope "Open Projects" means but looking into the IDE Log I found:
SEVERE [org.openide.util.RequestProcessor]: Error in RequestProcessor org.netbeans.modules.search.SearchTask
java.lang.IllegalArgumentException: newPosition > limit: (1 > 0)
at java.base/java.nio.Buffer.createPositionException(Buffer.java:352)
at java.base/java.nio.Buffer.position(Buffer.java:327)
at java.base/java.nio.ByteBuffer.position(ByteBuffer.java:1551)
at java.base/java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:623)
at org.netbeans.api.queries.FileEncodingQuery$ProxyCharset$ProxyDecoder.decodeLoop(FileEncodingQuery.java:191)
at java.base/java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:586)
Caused: java.nio.charset.CoderMalfunctionError
at java.base/java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:588)
at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:385)
at java.base/sun.nio.cs.StreamDecoder.lockedRead(StreamDecoder.java:217)
at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:171)
at java.base/java.io.InputStreamReader.read(InputStreamReader.java:188)
at java.base/java.io.BufferedReader.fill(BufferedReader.java:160)
at java.base/java.io.BufferedReader.implRead(BufferedReader.java:196)
at java.base/java.io.BufferedReader.read(BufferedReader.java:181)
at org.netbeans.modules.search.matcher.LineReader.readNext(LineReader.java:70)
at org.netbeans.modules.search.matcher.SingleLineStreamMatcher.getTextDetailsSL(SingleLineStreamMatcher.java:102)
at org.netbeans.modules.search.matcher.SingleLineStreamMatcher.checkMeasuredInternal(SingleLineStreamMatcher.java:68)
at org.netbeans.modules.search.matcher.AbstractMatcher.check(AbstractMatcher.java:53)
at org.netbeans.modules.search.matcher.DefaultMatcher.checkMeasuredInternal(DefaultMatcher.java:93)
at org.netbeans.modules.search.matcher.AbstractMatcher.check(AbstractMatcher.java:53)
at org.netbeans.modules.search.BasicComposition.start(BasicComposition.java:78)
at org.netbeans.modules.search.SearchTask.run(SearchTask.java:87)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1403)
at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:287)
[catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2018)
So I assume there is somewere a for Netbeans problematic file. However, this should not stop the search.
Language / Project Type / NetBeans Component
Multimodule Java Maven Project (no java modules)
How to reproduce
That is a good question. Since I cannot make a project copy of mine, I still search for the problematic file.
Did this work correctly in an earlier version?
No / Don't know
Operating System
Windows
JDK
21
Apache NetBeans packaging
Apache NetBeans provided installer
Anything else
No response
Are you willing to submit a pull request?
No
Was this "Find" or "Replace"?
Edit: Which JDK exactly was used? (Help Menu -> About, Lines Java + Runtime)
Was find from menu or popup. this seems to happen using scope Open Projects. Jdk version follows ...
duplicate of https://github.com/apache/netbeans/issues/6671
can also happen during indexing: https://github.com/apache/netbeans/issues/4762
also see the question in https://github.com/apache/netbeans/issues/6671#issuecomment-1806606757
Java: 21.0.4; OpenJDK 64-Bit Server VM 21.0.4+7-LTS
@wumpz which Vendor?
To narrow the problem down, you could invoke Find from the "Files" tab and descent through the directory tree until you pinpoint the problematic file. This should reduce the number of attempts drasticly.
as mentioned on the other issue, the exception is intended for search/replace since the file must be correctly decodeable when replacing something in it. So if this is happening on find it could be that some search action is using the wrong code path somewhere or forgets to set strict=false.
If this happens during serach/replace, its really not much we can do about it, maybe improve the message to list the file and skip it.
The fact, that an java.nio.charset.CoderMalfunctionError (core keyword being Error) is raised, indicates a deeper problem. I learned, that catching Exception is discouraged and catching Error is just plain wrong (with very few exceptions). So when this happens when using a decoder, this is either a bug in the JDK or in our usage of the facilities.
That is why I'd like to have a reproducer and know where this comes from.
I don't disagree, I just mean that there is another layer to that, NB controls when the error should be thrown or not:
decoder.onMalformedInput(CodingErrorAction.REPORT);
it is meant to only propagate the error on search/replace. All what I am saying is that if this happens already during plain search, there might be more to that.
edit: i am also sure if the decoder API would be designed today, it wouldn't extend Error.
this might be a good place catch CoderMalfunctionError, but this is only for the SingleLineStreamMatcher, there are likely more places (indexing included) - thats why it would be good to have a reproducer for this.
https://github.com/apache/netbeans/blob/4d6ddb418594a6f3da24397a32aa4725d576cd53/platform/api.search/src/org/netbeans/modules/search/matcher/SingleLineStreamMatcher.java#L78-L81
@matthiasblaesing Sorry. Did not see your mentioning. This is an Eclipse Temurin Release.
I also reproduce this bug since a long time, with multiple Netbeans versions. I now use NetBeans IDE 25 on Linux. Java version is 21.0.6, OpenJDK 64-Bit Server VM 21.0.6+2. I finally found the culprit and can reproduce this bug with only one file in a project. Either using search or with automatic scanning. Here is the file : error_file.txt . You'll have to change extension. I used .gpx but .xml also works.
The xml encoding property say "UTF-8" but the file is not UTF-8 encoded. There are accentuated characters in the file.
Hope this helps
@keosion thanks for the reproducer. Will check if this can be improved for NB 26.