Deobfuscated stack trace message and line-specific stack traces

[brad]

Hi,

Two issues that often frustrate me with GWT deobfuscated stack traces:
a) The stack trace is deobfuscated, but the error message is not, so you
get something like "com.google.gwt.core.client.JavaScriptException:
(TypeError) : Cannot read property 'a' of undefined".
b) The stack trace refers to methods headers, rather than specific lines.

In many cases, neither of these is a big deal, but if the message is
obscure and the method in question is long it can make debugging difficult.
Is there anything that can be done to work around this (compiler
properties, etc.). This is particularly for debugging a deployed
application, not locally using super dev mode.

Thanks,
Brad

[Paul Robinson]

I always deploy a version compiled with emulated stack traces alongside the
regular version so that if a problem can be replicated, I can get a proper
stack trace.

But I still share your pain. Trying to work out which line of obfuscated
JavaScript could possibly have given a null pointer exception can be quite
tedious.

I'd be (happily) surprised if it's possible to improve stack traces or
error messages without slowing things down.

Paul

Post by brad
Hi,
a) The stack trace is deobfuscated, but the error message is not, so you
(TypeError) : Cannot read property 'a' of undefined".
b) The stack trace refers to methods headers, rather than specific lines.
In many cases, neither of these is a big deal, but if the message is
obscure and the method in question is long it can make debugging difficult.
Is there anything that can be done to work around this (compiler
properties, etc.). This is particularly for debugging a deployed
application, not locally using super dev mode.
Thanks,
Brad
--
You received this message because you are subscribed to the Google Groups
"GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Jens]

Depending on your browser versions you support, you could try enabling
source maps for other user agents as well. Currently it is only active for
safari permutation. If you deploy the generated source maps, the
StackTraceDeobfuscator could use them on the server to make better stack
traces.

You would need to add some additional rebind rules to your project in the
same manner as
in https://github.com/gwtproject/gwt/blob/master/user/src/com/google/gwt/core/CoreWithUserAgent.gwt.xml

At the end it all depends on wether or not the browser reports column
numbers in addition to line numbers then throwing an error. Because in GWT
generated JS every method has its own line and is a one-liner (white
spaces, new lines within method removed) itself, browsers which only report
line numbers basically only report the JS method that caused the error.
Only with a column number it is possible to also figure out the expression
within the method. Of course GWT could technically produce a JS file which
has every single statement/expression on its own line, but that would add a
significant amount of new line characters and thus would make your app
larger (even though gzip compression might mitigate that issue). If GWT
would do that, then column numbers wouldn't be required.

Using the above source maps based solution only works in browsers which
support column numbers because source maps encoding is based on column
numbers.
See http://www.mattzeunert.com/2016/02/14/how-do-source-maps-work.html if
interested.

-- J.

[Pavlo Iatsiuk]

Hi,

I do not know about version 2.8, but for 2.6 we did next:
- put value "PRETTY" in the pom.xml for gwt plugin
- put next loggin settings in the application gwt config file

<inherits name="com.google.gwt.logging.Logging"/>
<set-property name="gwt.logging.logLevel" value="FINEST"/>
<set-property name="gwt.logging.consoleHandler" value="ENABLED"/>
<set-property name="gwt.logging.simpleRemoteHandler" value="DISABLED" />
<set-property name="gwt.logging.popupHandler" value="DISABLED" />


<set-property name="compiler.stackMode" value="emulated" />
<set-configuration-property name="compiler.emulatedStack.recordLineNumbers"
value="true"/>
<set-configuration-property name="compiler.emulatedStack.recordFileNames"
value="true"/>


as result we had a proper class names and line numbers in the stack-trace
massages

Post by brad
Hi,
a) The stack trace is deobfuscated, but the error message is not, so you
(TypeError) : Cannot read property 'a' of undefined".
b) The stack trace refers to methods headers, rather than specific lines.
In many cases, neither of these is a big deal, but if the message is
obscure and the method in question is long it can make debugging difficult.
Is there anything that can be done to work around this (compiler
properties, etc.). This is particularly for debugging a deployed
application, not locally using super dev mode.
Thanks,
Brad