jruby - 有没有办法在 jruby 中获得合理的堆栈跟踪？

Question

当我的 jruby 程序意外启动并向我提供堆栈跟踪时，这几乎是不可理解的。它充满了显然来自内部解释器的行，这让我很难弄清楚我的实际程序的实际调用堆栈是什么。

类似的东西(只是摘录):

    from CachingCallSite.java:326:in `cacheAndCall'
    from CachingCallSite.java:170:in `call'
    from CallOneArgNode.java:57:in `interpret'
    from LocalAsgnNode.java:123:in `interpret'
    from NewlineNode.java:105:in `interpret'
    from BlockNode.java:71:in `interpret'
    from RescueNode.java:222:in `executeBody'
    from RescueNode.java:117:in `interpret'
    from EnsureNode.java:96:in `interpret'
    from ASTInterpreter.java:74:in `INTERPRET_METHOD'
    from InterpretedMethod.java:161:in `call'
    from DefaultMethod.java:178:in `call'
    from CachingCallSite.java:316:in `cacheAndCall'

而且这些不仅仅是散布在我的实际程序中的调用堆栈行——我的实际程序的调用堆栈似乎根本没有出现在堆栈跟踪中。使它对于帮助我找出实际引发异常的预期目的没有那么有用。

我想我记得在过去的某个时候找出一些命令行参数给 jruby，与调试或 JIT 或其他东西相关，这将再次导致合理合理的堆栈跟踪(可能以 JIT 性能为代价或某物？)。

但是试图再次找到它，我运气不好，花了很多时间试图找到 jruby 文档、谷歌搜索等，但没有找到任何导致合理堆栈跟踪的命令行参数。

有人知道吗？

Answer 1

我会经常force compilation使用 jruby.compile.mode=FORCE 编译代码，因为编译后的代码将在堆栈跟踪中包含 Ruby 名称和行号。这通常会使事情变得更慢，所以我不会一直打开它。

As of JRuby 1.7.10 ，尝试将 jruby.rewrite.java.trace 设置为 true。

编辑

从同一个 Twitter 讨论中，另一个想法是使用

rescue NativeException
  raise
end

这也可能有所帮助。当然，您必须知道异常发生的位置，但它应该在紧要关头有所帮助。