ReTrace's default regex fails to process the following kind of stack-trace (produced when running from an executable JAR file):
com.google.inject.internal.util.$ComputationException: java.lang.AbstractMethodError: com.google.inject.internal.cglib.reflect.$FastClass.n([Ljava/lang/Class;)I
at com.google.inject.internal.util.$MapMaker$StrategyImpl.a(MapMaker.java:553) ~[vtlr-backend-1.0-SNAPSHOT.jar:na]
at com.google.inject.internal.util.$MapMaker$StrategyImpl.a(MapMaker.java:419) ~[vtlr-backend-1.0-SNAPSHOT.jar:na]
at com.google.inject.internal.util.$CustomConcurrentHashMap$ComputingImpl.get(CustomConcurrentHashMap.java:2041) ~[vtlr-backend-1.0-SNAPSHOT.jar:na]
Specifically, ~[vtlr-backend-1.0-SNAPSHOT.jar:na] found at the end of each line seem to throw it off. Is it possible to update the regex to handle this?
FYI, I tracked this syntax back to Logback ch.qos.logback.classic.spi.ThrowableProxyUtil.subjoinPackagingData():121
The following regex should match the packaging data at the end of the line, if it exists.
(~?[[^]]*])?$
I'm very reluctant to adapt the default regular expression for one format of one logging framework. For now, you should use the -regex option to specify your own regular expression.
Note that you should generally use a non-capturing group in these expressions: (?:.....)
Ticket moved from /p/proguard/bugs/522/
Perhaps instead of changing the default regex, we could add a pulldown menu of common regular expressions to Proguard GUI so users can select the JDK default, Logback default, etc. Right now, there is no way to change the regex in the GUI as far as I can tell.
Note that this stack trace format including packaging/versioning info is now also the default for log4j 2.0. Now that the two most widely used logging framworks (log4j and logback) use that format, I suspect a lot of people would be happy not having to fiddle with regexes themselves.
I've extended the regular expression for the upcoming ProGuard 5.3:
Last edit: Eric Lafortune 2015-12-01