Stack trace not showing correct line number

[Carl]

We use source maps to log stack traces from the GWT client on the server

<set-property name="compiler.stackMode" value="native" />

<set-property name="compiler.useSourceMaps" value="true"/>

<set-property name="compiler.emulatedStack" value="true" />

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

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

and use StackTraceDeobfuscator to deobfuscate

private StackTraceDeobfuscator getStackTraceDeobfuscator(ServletContext servletContext) {

String relativeWebPath = "WEB-INF/deploy/appimpl/symbolMaps";

String symbolMapsDirectory = servletContext.getRealPath(relativeWebPath);

StackTraceDeobfuscator std = StackTraceDeobfuscator.fromFileSystem(symbolMapsDirectory);

return std;

}

which gives us this stack trace:

at java.lang.Throwable.Throwable(Throwable.java:58)

at java.lang.Exception.Exception(Exception.java:25)

at java.lang.RuntimeException.RuntimeException(RuntimeException.java:25)

at java.lang.NullPointerException.NullPointerException(NullPointerException.java:27)

at client.CustomMenu.simulateClientCrash(CustomMenu.java:3734)    <--- first line of method

at client.CustomMenu$12.onClick(CustomMenu.java:1686)

..

The problem is that the trace always gives us the first line of the method and not the line where the exception is thrown.

CustomMenu.java

3734  private void simulateClientCrash() {     <--- first line of method

3735      if (true) {

3736        throw new NullPointerException();     <--- exception is thrown

3737   }

3738  }

This is not a big deal if the method is short but can be quite a pain if the method is longer.

Why is this? Can it be fixed?

[Freddy Boucher]

Line Number is only accurate if you compile with:

  <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" />

But it will double the size of your compiled JS file!!!

With:

<set-property name="compiler.stackMode" value="native" />

you will only get the line number of your method declaration (but not the exact line inside the method).

I have a demo project where you can play with that: https://gwt-storage-objectify.appspot.com

Basically what we do at work, is to compile the project twice (one time with emulated and one time with native).

By default we serve the native JS (that is smaller) but if a User faces an Exception, then at next reload we serve the emulated JS for this specific User so if an Exception happens again, we have the exact StackTrace.

Freddy

[Jens]

In addition to what Freddy already said:

Native JS exceptions (which you get with "compiler.stackMode = native") should provide a line number as well as a column number. However not all browsers do this, some only report a line number. For those browsers that do not provide a column, the stack trace points to the start of the method because GWT's final JS output places each JS method on its own, single line. So if any exception occurs in the method, the line number matches the start of the method. Theoretically GWT could put each JS statement on its own line for those browsers but that would increase the JS size (additional carriage return character for each statement).

Chrome for example provides line and column numbers and thus the exception points to the concrete line within the method.

If you use "compiler.stackMode = emulated" then GWT inserts code to track code lines, thus the app will be roughly twice as large (and quite a bit slower).

-- J.

[Craig Mitchell]

In my experience, with "compiler.stackMode = native", even when using Chrome, you don't get line numbers.  You have to have "compiler.stackMode = emulated".

[Carl]

Thank you for your inputs. We now understand a little more what's going on and a possible workaround. None of the browsers we tested (Chrome, Safari or Edge) give us line numbers. The emulated version is too large and serving it to our users is not an option. If we can't find the line with the exception using native we'll have to upload the emulated version and recreate the conditions as admin. A bit time consuming but it works.

If there were a version with working line numbers weighing in slightly heavier than native but not as heavy as emulated we might go for that. Wishful thinking...

[Jens]

In my experience, with "compiler.stackMode = native", even when using Chrome, you don't get line numbers.  You have to have "compiler.stackMode = emulated".

Today I have looked at a stack trace and it did show the correct line number when using Chrome. But the app uses GWT trunk and not a released GWT version, so maybe something changed and is currently broken in 2.8.2.

-- J.

[管理人です。]

Gwt do not show trace .

But you can show browser trace.

Example chrome is depeloper mode .

2019年6月20日(木) 2:56 Jens <jens.ne...@gmail.com>:

In my experience, with "compiler.stackMode = native", even when using Chrome, you don't get line numbers.  You have to have "compiler.stackMode = emulated".

Today I have looked at a stack trace and it did show the correct line number when using Chrome. But the app uses GWT trunk and not a released GWT version, so maybe something changed and is currently broken in 2.8.2.

-- J.

--
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 email to google-web-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/35af2790-634c-40b6-a215-b48ee36a7422%40googlegroups.com.

[Paul Robinson]

I haven't seen proper stack traces in my app without emulation in Chrome, even in older versions of GWT.

Is it possible there's a trick to making it show the real line instead of the function start, rather than a bug in 2.8.2?

Paul