我们正在尝试将未被捕获的GWT异常(我们使用GWT 2.5 rc1)发送到我们的服务器以进行日志记录和调试.我们想要对异常堆栈跟踪进行反混淆处理,否则它将毫无用处.
经过一些调查,我在GWT和WebModeExceptions中找到了7个包含有价值信息的异常处理技巧.
因此,我们创建了一个GWT UncaughtExceptionHandler,它使用自定义RPC服务来传输带有堆栈跟踪的异常.这很好.
如WebModeExceptions反混淆部分所述,我们在GWT模块中启用了堆栈跟踪仿真:
<set-property name="compiler.stackMode" value="emulated" />
<set-configuration-property name="compiler.emulatedStack.recordLineNumbers"
value="true" />
Run Code Online (Sandbox Code Playgroud)
现在我们的堆栈跟踪看起来像这样:
com.google.gwt.core.client.JavaScriptException: (TypeError) : Cannot call method 'pp' of null
Unknown.aT(Unknown Source:174)
Unknown.AVa(Unknown Source:501)
Unknown.YF(Unknown Source:29)
Unknown.Lqb(Unknown Source:138)
...
Run Code Online (Sandbox Code Playgroud)
对我来说似乎没问题,因为它包含混淆的方法名称和行号,这似乎是WebModeExceptions反混淆部分中描述的所需内容.
然后我们使用-extra参数编译GWT模块以获取symbolmaps.
我们的自定义日志服务使用symbolMaps目录来调用com.google.gwt.logging.server.StackTraceDeobfuscator.我们使用X-GWT-Permutation http头来调用反混淆器.我介入了deobfuscate方法,以确保它可以加载符号映射.它可能.我验证了使用的symbolMap文件名与GWT模块的*.cache.js文件名匹配.它确实匹配.
所以基本上,服务这样做:
// Create the deobfuscator
String dir = getSymbolMapsDirPath();
StackTraceDeobfuscator deobfuscator = new StackTraceDeobfuscator(dir);
// request is the HttpServletRequest
String strongName = request.getHeader(RpcRequestBuilder.STRONG_NAME_HEADER);
// Deobfuscate the stack trace
exception.setStackTrace(
deobfuscator.deobfuscateStackTrace(exception.getStackTrace(), strongName));
// Log the exception
logger.severe("Uncaught GWT exception", exception);
Run Code Online (Sandbox Code Playgroud)
最终结果是堆栈跟踪不会被反混淆.有时,某些行会被错误的类和方法名称反转,但仅此而已.查看symbolMap文件时,堆栈跟踪中的实际符号与symbolMap文件中的任何符号都不匹配.
知道我们在这里做错了什么吗?
编辑:我尝试了RemoteLoggingServiceImpl,我得到了相同的结果.
经过进一步调查后-XenableClosureCompiler,我们使用的新GWT编译器选项似乎生成的代码不会输出使用编译器生成的符号映射的堆栈跟踪.删除该选项后,可以成功地对堆栈跟踪进行反混淆处理.
作为旁注,启用堆栈跟踪反混淆所需的编译器和GWT模块选项(在我的问题中描述并删除闭包编译器选项)使我们的最终js文件比以前大两倍.
| 归档时间: |
|
| 查看次数: |
3793 次 |
| 最近记录: |