Support remote logging with stack trace deobfuscation in SuperDevMode

[dankurka]

Originally reported on Google Code with ID 7693

Stack trace deobfuscation won't work as-is in Super Dev Mode because the compiled code
doesn't match what's known to the server. We should probably send all remote logging
messages to the code server (and log them there and provide a UI). Perhaps they could
then be sent to back to the original server after deobfuscation? Or perhaps we should
just log a message saying that Super Dev Mode is in use and to see the code server
for logs?

Current as of GWT 2.5 rc2.

Reported by skybrian@google.com on 2012-09-25 21:07:21

[dankurka]

Perhaps the code server should provide a remote API for deobfuscating stack traces.
This should be callable from JavaScript and GWT (when Super Dev Mode is on).

What are the use cases for this?

Reported by skybrian@google.com on 2014-04-10 18:51:25

[dankurka]

re: https://groups.google.com/d/msg/google-web-toolkit/QSEjbhhHB4g/VWZDExAZIW4J

"Brian: how hard would it be to alter the code server to serve the symbol map as well,
at some special URL?"

It would not be that hard but it seems expensive to download it to deobfuscate one
stack trace?

Reported by skybrian@google.com on 2014-04-11 17:58:49

[dankurka]

If the server is on the same host as SDM then it could be as easy as starting SDM with
something like -deploy /path/to/exploded/war and let StackTraceDeobfuscator know to
not cache symbol maps.

However if the server is on an external host then you can only:
1.) download symbol maps from SDM each time the server must deobfuscate a stack trace
(the server can not cache symbol maps as it does not know if client code has been changed).
Gzip will do a great job in compressing symbol maps as they contain a lot of reoccurring
strings like package names.
2.) let StackTraceDeobfuscator delegate the work to a SDM web service (which would
make the SDM code server not just a code server anymore). 

I think I would prefer 2.) as it would also allow client only apps to call the SDM
web service from JS/GWT directly.

Reported by jens.nehlmeier on 2014-04-11 19:16:38

[dankurka]

"(the server can not cache symbol maps as it does not know if client code has been changed)"

I'm probably missing something, but if the client code has been changed, wouldn't the
permutation strong name be different then? If yes, then caching is no problem, and
then I'm all for (1) due to its simplicity and symmetry with how source maps are served.

In any case it could have been a storm in a bottle after all.
I looked again at the stacktraces generated in SDM mode, and they are, ahem, not that
bad after all:
<snip>
com.google.web.bindery.event.shared.UmbrellaException: Exception caught: Exception
caught: XXX
Unknown.$collect(JsArrayString.java:42)
Unknown.fillInStackTrace_1(StackTraceCreator.java:174)
Unknown.fillInStackTrace(StackTraceCreator.java:508)
Unknown.$fillInStackTrace(Throwable.java:72)
Unknown.$$init_17(Throwable.java:46)
Unknown.Throwable_2(Throwable.java:56)
Unknown.Exception_2(Exception.java:33)
Unknown.RuntimeException_2(RuntimeException.java:33)
Unknown.UmbrellaException_1(UmbrellaException.java:71)
Unknown.$doFire_0(SimpleEventBus.java:203)
Unknown.$fireEvent_2(SimpleEventBus.java:88)
Unknown.fireEvent_15(SimpleEventBus.java:52)
Unknown.$fireEvent_4(ChosenImpl.java:506)
Unknown.$resultSelect(ChosenImpl.java:865)
</snip>

The big selling point of the current SDM stacktraces is that they already *somehow*
have the Java file and line number in them. How does this magic work?!
Also, the function name more or less matches the original Java method name... What
else can I want?

(BTW: This is all with GWT 2.5.1.)

Reported by ivan.markov on 2014-04-11 22:20:22

[dankurka]

They are actually JavaScript names, but when you compile using -style pretty (as SuperDevMode
always does), the JavaScript names are close to the Java names.

You can see they aren't exactly the same because there are suffixes to remove ambiguity
as JavaScript globals: Throwable_2 and not Throwable.

It also doesn't give you the class, but going to the Java line should clear that up.

Reported by skybrian@google.com on 2014-04-11 22:31:21

[dankurka]

Because SuperDevMode have many issues with meaningfull stacktraces (especially, when
exception is wrapped several times) it will be good to treat this issue with highest
priority.

If SuperDevMode will JUST send all remote logging messages to the Code Server console
- it would be awesome! It would be significant breathe in tedious SuperDevMode debugging.

Meaningfull stacktraces - is extremely helpful. If this issue will be fixed, it will
be good to even suggest using Remove Logging in SuperDevMode daily usage, like via
http://www.gwtproject.org/articles/superdevmode.html guide.

>Perhaps they could then be sent to back to the original server after deobfuscation?
Don't think this needed, Prod Mode remote logging needed to collect logs from a many
users (in BD, other big log file), and not needed for dev.
Apart, SuperDevMode remote logging - mostly only way to have deobfuscated stacktases
for development.

>provide a UI
Don't think this needed too. Its logical in SuperDevMode to send all remote logging
messages to the Code Server console.
In my NetBeans IDE, Code Server have an output window, any exception(with stacktrace)
in this window is auto highlighted with clickable! links to source code. It is Better
than any UI. 
More, Browser already have its logging UI - "console" JS object, it is also better
than any UI. 
But, browsers console not vary helpful for stack-trace logging for now: 
* Chrome, FF do not detect GWT obsfucated stacktaces as stacktreces, as result - not
resolve them by source-maps, and don't highlight by links, like using console.log(e),
or console.error(e).
* To show deobsfucated stacktaces - need roung-trip from code-server, but same - it
will be just plain text in browser console.

Here manual workaround for this issue on web-server (I use this, in extreme cases,
or when deobsfucated stacktaces really needed):
 public class GwtLoggingServlet extends RemoteLoggingServiceImpl{
    @Override
    public void init(final ServletConfig config) throws ServletException {
        super.init(config);
        //Manually(yes change the code each time) or dynamically (code should auto find
a folder) set last location of SuperDevMode compile folder, like below:
        setSymbolMapsDirectory("C:\\Users\\Administrator\\AppData\\Local\\Temp\\gwt-codeserver-1055091360633699941.tmp\\com.ajaxdatabase.ajaxwind.Main\\compile-3\\extras\\com.ajaxdatabase.ajaxwind.Main\\symbolMaps\\");
    }
}

Reported by vitrilo on 2014-05-26 09:21:34

[dankurka]

I don't know what you mean by "Code server console" since Super Dev Mode's code server
doesn't have a console (yet). Perhaps you mean that Super Dev Mode should log browser
messages to stdout or stderr? Perhaps this is what NetBeans displays?

Reported by skybrian@google.com on 2014-05-27 21:25:14

[dankurka]

>Perhaps you mean that Super Dev Mode should log browser messages to stdout or stderr?
>Perhaps this is what NetBeans displays?
Correct - stdout or stderr.

Reported by vitrilo on 2014-05-27 21:57:38

[dankurka]

Here source code of workaround - GwtSuperDevModeLoggingServlet.java.
To use - change constants inside it.

Reported by vitrilo on 2014-05-28 14:14:07

---

• Attachment: GwtSuperDevModeLoggingServlet.java

[dankurka]

I think we should start with pushing Chrome to apply source maps to stack traces. That's
much simpler and pretty useful alternative:
 https://code.google.com/p/chromium/issues/detail?id=357958

@Brian, what do you think?

Reported by goktug@google.com on 2014-07-11 22:14:29