You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This results in an NPE while creating the replacement StackTraceElement, preventing reading the exception.
The Chromium issue is that when building a stack element of the form at method (file:row:col), the method name now may have a new prefix. This is not found in the symbol map file, so cannot be deobfuscated (though sourcemaps can try to take the row/col and figure out which file it should have come from). Example JS stack trace (with -style PRETTY):
java.lang.RuntimeException: Runtime Exception
at RuntimeException_0.createError (com.google.gwt.user.LoggingRPCSuite.JUnit-0.js:912:10)
at RuntimeException_0.initializeBackingError (com.google.gwt.user.LoggingRPCSuite.JUnit-0.js:946:40)
at RuntimeException_0.Throwable_0 (com.google.gwt.user.LoggingRPCSuite.JUnit-0.js:877:8)
at RuntimeException_0.Exception_0 (com.google.gwt.user.LoggingRPCSuite.JUnit-0.js:961:15)
at new RuntimeException_0 (com.google.gwt.user.LoggingRPCSuite.JUnit-0.js:970:15)
at $throwException (com.google.gwt.user.LoggingRPCSuite.JUnit-0.js:4315:14)
at LoggingRPCTest.testStackMapDeobfuscation (com.google.gwt.user.LoggingRPCSuite.JUnit-0.js:4369:5)
Instead of new RuntimeException_0, our symbol maps expect RuntimeException_0, so this prefix needs to be removed.
The text was updated successfully, but these errors were encountered:
Improves accuracy of deobfuscated stack traces by using the best answer
between original JS names, symbol maps, and source maps, by both
avoiding taking an identifier from the sourcemap if none is provided,
and normalizing away chromium specific prefixes in stack trace elements.
Fixesgwtproject#9996
Follow-up gwtproject#9936
Improves accuracy of deobfuscated stack traces by using the best answer
between original JS names, symbol maps, and source maps, by both
avoiding taking an identifier from the sourcemap if none is provided,
and normalizing away chromium specific prefixes in stack trace elements.
Fixesgwtproject#9996
Follow-up gwtproject#9936
Improves accuracy of deobfuscated stack traces by using the best answer
between original JS names, symbol maps, and source maps, by both
avoiding taking an identifier from the sourcemap if none is provided,
and normalizing away chromium specific prefixes in stack trace elements.
Fixesgwtproject#9996
Follow-up gwtproject#9936
Improves accuracy of deobfuscated stack traces by using the best answer
between original JS names, symbol maps, and source maps, by both
avoiding taking an identifier from the sourcemap if none is provided,
and normalizing away chromium specific prefixes in stack trace elements.
Fixes#9996
Follow-up #9936
GWT version: HEAD-SNAPSHOT
Browser (with version): any/chrome
Operating System: any
This issue is discussing two related issues, one a regression in GWT since #9936 and the other a regression in the past few years in chromium.
The GWT regression is mentioned at StackTraceDeobfuscator sometimes produces total nonsense #9931 (comment):
This results in an NPE while creating the replacement StackTraceElement, preventing reading the exception.
The Chromium issue is that when building a stack element of the form
at method (file:row:col)
, the method name now may have anew
prefix. This is not found in the symbol map file, so cannot be deobfuscated (though sourcemaps can try to take the row/col and figure out which file it should have come from). Example JS stack trace (with -style PRETTY):Instead of
new RuntimeException_0
, our symbol maps expectRuntimeException_0
, so this prefix needs to be removed.The text was updated successfully, but these errors were encountered: