Wrong deobfuscated stack traces

[Jens]

In production we sometimes get exceptions and we log them using StackTraceDeobfuscator class on the server (either symbol maps or source maps, depending on browser). However these stack traces are often broken when comparing the member with the file it should live in.

Some examples:

at Unknown.removeChild(Unknown@-1)

at com.google.gwt.dom.client.Node.$removeChild(com/google/common/base/Joiner.java:198)

at com.google.gwt.user.client.ui.SimplePanel.$remove(com/google/common/collect/super/com/google/common/collect/ImmutableList.java:41)

at com.google.gwt.user.client.ui.SimplePanel.remove(com/google/common/collect/super/com/google/common/collect/ImmutableMap.java:239)

at com.google.gwt.user.client.ui.SimplePanel$1.remove(SimplePanel.java:93)

at com.google.gwt.user.client.ui.Panel.$clear(com/google/gwt/user/client/ui/Panel.java:75)

at java.lang.Throwable.Throwable(com/google/gwt/emul/java/util/AbstractCollection.java:68)

at java.lang.RuntimeException.RuntimeException(com/google/gwt/emul/java/util/AbstractList.java:208)

at com.google.web.bindery.event.shared.UmbrellaException.UmbrellaException(com/google/common/collect/super/com/google/common/collect/ForwardingImmutableMap.java:108)

at com.google.web.bindery.event.shared.SimpleEventBus.$doFire(com/google/common/collect/super/com/google/common/collect/ImmutableList.java:281)

at com.google.gwt.place.shared.PlaceController.$goTo(com/google/gwt/emul/java/util/AbstractMap.java:167)

at com.google.web.bindery.event.shared.UmbrellaException.UmbrellaException(UmbrellaException.java:656)

at com.google.gwt.event.shared.UmbrellaException.UmbrellaException(com/google/gwt/http/client/Request.java:247)

at com.google.gwt.event.shared.HandlerManager.$fireEvent(HandlerManager.java:638)

Any idea how this could happen and where to look at, or is this kind of expected with current compiler? 

-- J.

[Roberto Lublinerman]

Looking at this traces it seems to me that the file/line is consistent but the member is completely off. That suggests that the wrong symbol map is being used.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/2303e9b2-bf7c-4f67-9bf4-7b3fe5b83145%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jens]

Looking at this traces it seems to me that the file/line is consistent but the member is completely off. That suggests that the wrong symbol map is being used.

It is stock GWT with just a single change wrt to Date serialization. We deploy what GWT gives us and the code chooses the symbol map using the permutation strong name transferred via the GWT-RPC as HTTP header (AbstractRemoteServiceServlet#getPermutationStrongName()). 

So I would say it is the correct symbol map and from the full exceptions I have seen so far the members itself are correct, but file/line is off here and there. You can see this in the first example. The stack of just the members is correct when calling Panel.clear() on a SimplePanel. However file name went crazy at some point and switches to some Guava stuff.

-- J.

[Grzegorz Nowak]

I think it's related to this: https://github.com/aepshteyn/gwt-stack-trace-kit (I'm not the author)

Greg