Community
Participate
Working Groups
java.util.regex.PatternSyntaxException: Dangling meta character '*' near index 0 * ^ at java.util.regex.Pattern.error(Pattern.java:1713) at java.util.regex.Pattern.sequence(Pattern.java:1878) at java.util.regex.Pattern.expr(Pattern.java:1752) at java.util.regex.Pattern.compile(Pattern.java:1460) at java.util.regex.Pattern.<init>(Pattern.java:1133) at java.util.regex.Pattern.compile(Pattern.java:823) at java.lang.String.replaceFirst(String.java:2146) at org.eclipse.cdt.make.internal.core.scannerconfig.gnu.GCCPerFileBOPConsoleParser.processCommand(GCCPerFileBOPConsoleParser.java:118) at org.eclipse.cdt.make.internal.core.scannerconfig.gnu.AbstractGCCBOPConsoleParser.processSingleLine(AbstractGCCBOPConsoleParser.java:300) at org.eclipse.cdt.make.internal.core.scannerconfig.gnu.AbstractGCCBOPConsoleParser.processLine(AbstractGCCBOPConsoleParser.java:141)
The exception is pointing to the line tokens[i]= token.replaceFirst(shortFileName, "SHORT_NAME"); //$NON-NLS-1$ Can you look in your build output for the line that could possibly cause the error? A line with an asterisk '*' that the parser could interpret as a file name.
(In reply to comment #1) > The exception is pointing to the line > tokens[i]= token.replaceFirst(shortFileName, "SHORT_NAME"); //$NON-NLS-1$ > > Can you look in your build output for the line that could possibly cause the > error? A line with an asterisk '*' that the parser could interpret as a file > name. Yes, I know. However, there should be no PatternSyntaxException. A simple Pattern.quote(shortFileName) should do.
(In reply to comment #2) > > Can you look in your build output for the line that could possibly cause the > > error? A line with an asterisk '*' that the parser could interpret as a file > > name. > Yes, I know. However, there should be no PatternSyntaxException. A simple > Pattern.quote(shortFileName) should do. I agree, but could you indulge my curiosity?
(In reply to comment #3) > > Yes, I know. However, there should be no PatternSyntaxException. A simple > > Pattern.quote(shortFileName) should do. > I agree, but could you indulge my curiosity? Sorry, I no longer have the build output at hand.
Created attachment 196742 [details] Committed fix I committed a slightly different fix which avoids the use of a regex pattern altogether, which should also be a little better in terms of performance.
Andrew, please review my fix.
*** cdt cvs genie on behalf of aleherbau *** Bug 346935 - [Scanner Discovery] PatternSyntaxException from build output parser [*] GCCPerFileBOPConsoleParser.java 1.29 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.core/src/org/eclipse/cdt/make/internal/core/scannerconfig/gnu/GCCPerFileBOPConsoleParser.java?root=Tools_Project&r1=1.28&r2=1.29
(In reply to comment #6) > Andrew, please review my fix. The fix certainly gets rid of the exception, although after looking a bit more closely I don't think it is the right solution. The purpose of the parser is to collect settings for the file being compiled, if the name contains star the parser has already failed to identify the file. I think the better solution is to quit processing the line as soon as we discovered that the file name is invalid or even better adjust parsing algorithm to reject the line way earlier. That is why I was interested to see the line from output, chances are that parsing went south way before that line of code. But I am unwilling to do any changes to parsing that close to the release and think your patch makes no harm, hence the '+'. Last question, does the exception prevent parser from parsing the rest of output? That would be really bad.
(In reply to comment #8) > (In reply to comment #6) > > Andrew, please review my fix. > The fix certainly gets rid of the exception, although after looking a bit more > closely I don't think it is the right solution. It does exactly the same as before, just without throwing an exception ;-) I am not trying to improve the heuristics of the build output parser. > Last question, does the exception prevent parser from parsing the rest of > output? That would be really bad. Yes, I think so. Looking at the stacktrace and code it seems the exception is not caught anywhere and thus makes an end to build output parsing.
