Bug 1179897

Summary: [RFE] Implement client-side JavaScript stacktrace de-obfuscation
Product: [oVirt] ovirt-engine Reporter: Vojtech Szocs <vszocs>
Component: RFEsAssignee: Alexander Wels <awels>
Status: CLOSED CURRENTRELEASE QA Contact: Pavel Novotny <pnovotny>
Severity: high Docs Contact:
Priority: unspecified    
Version: ---CC: bugs, gklein, iheim, jbelka, lsurette, mgoldboi, rbalakri, sbonazzo, yeylon, ykaul
Target Milestone: ovirt-3.6.2Keywords: Improvement
Target Release: 3.6.2.6Flags: rule-engine: ovirt-3.6.z+
rule-engine: exception+
rule-engine: planning_ack+
ecohen: devel_ack+
pstehlik: testing_ack+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-03-11 07:21:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: UX RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1179862    
Bug Blocks:    

Description Vojtech Szocs 2015-01-07 18:25:44 UTC
Uncaught JavaScript errors will normally result in obfuscated stacktraces, assuming the WebAdmin/UserPortal GWT application is running in compiled (production, non-debug) mode.

There should be a way to visualize and de-obfuscate stacktraces for any uncaught client-side exceptions. GWT SDK supports (server-side) stacktrace de-obfuscation via StackTraceDeobfuscator utility.

Example workflow:
1, client (e.g. WebAdmin) asks Engine to de-obfuscate stacktrace (HTTP request)
2, Engine servlet picks up the request, uses StackTraceDeobfuscator utility to process request

Note that step 2, requires that appropriate symbol maps are available to Engine (to be read from local filesystem by StackTraceDeobfuscator utility).

Bug 1179862 therefore needs to be solved before solving this bug.

Comment 1 Einav Cohen 2015-01-07 18:34:59 UTC
related to the client-side logging - see also bug 1049409. 

(In reply to vszocs from comment #0)
> ...
> Bug 1179862 therefore needs to be solved before solving this bug.

setting this bug to Depend On Bug 1179862.

Comment 2 Vojtech Szocs 2015-01-12 15:04:40 UTC
Alternative approach: use GWT emulated stack trace feature:

http://stackoverflow.com/questions/10740608/negative-performance-implications-of-using-gwt-emulated-stack-trace

Comment 3 Vojtech Szocs 2015-05-19 11:28:06 UTC
(In reply to vszocs from comment #2)
> Alternative approach: use GWT emulated stack trace feature:
> 
> http://stackoverflow.com/questions/10740608/negative-performance-
> implications-of-using-gwt-emulated-stack-trace

Above refers to ability to compile GWT application so that it already presents un-obfuscated stack trace for any client-side exception. However, this has the downside of significantly increased JavaScript output (due to embedding original Java meta-data) which hinders the end-user experience, especially on older browsers.

What we could do:

* during Engine build, compile two variants of WebAdmin/UserPortal (one using "native" stack traces, one using "emulated" stack traces)

* add new Engine config option, e.g. "EmulateGWTStackTrace" with default value "false" (to preserve existing behavior)

* when serving WebAdmin/UserPortal HTML page, check "EmulateGWTStackTrace" and if "true", load the (heavier) variant that uses un-obfuscated stack traces

As mentioned in comment #0 the other option is to do GWT stack trace de-obfuscation on server (much lower client-side performance impact, but server-side changes required).

Comment 4 Alexander Wels 2016-01-08 15:41:05 UTC
Went with the GWT stack trace de-obfuscation method from comment #0. Utilizing part of the existing GWT remote logging framework.

Comment 5 Vojtech Szocs 2016-01-11 15:56:42 UTC
(In reply to Alexander Wels from comment #4)
> Went with the GWT stack trace de-obfuscation method from comment #0.
> Utilizing part of the existing GWT remote logging framework.

From implementation perspective this seems to be the most simple approach.

It's important to note that this feature works *only* when users install the optional package containing GWT symbol maps, refer to [1] for details.

[1] http://www.ovirt.org/OVirt_Engine_Debug_Obfuscated_UI#Making_sure_we_have_the_right_symbol_maps

Comment 6 Einav Cohen 2016-01-18 20:54:26 UTC
will be extremely useful when needing to debug issues originating from the UI code -> re-targeting for 3.6.

Comment 7 Pavel Novotny 2016-03-03 22:18:28 UTC
Verified in rhevm-3.6.3.4-0.1.el6
Symbol maps packages:
rhevm-userportal-debuginfo-3.6.3.4-0.1.el6
rhevm-webadmin-portal-debuginfo-3.6.3.4-0.1.el6

Symbol maps location: /usr/share/ovirt-engine/gwt-symbols/{userportal,webadmin}/


Example for debugging of GWT exception on Firefox 38 ESR @ Linux, en_US locale:

Locating GWT permutation in HTTP headers:
-~-
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
X-GWT-Module-Base: https://engine.example.com/ovirt-engine/webadmin/
X-GWT-Permutation: C2A1F45ED54CD712A69A65581DAFB343
-~-

Symbol map file to use: /usr/share/ovirt-engine/gwt-symbols/webadmin/C2A1F45ED54CD712A69A65581DAFB343.symbolMap