Is there any way to get reasonable stack traces in jruby?

Question

When my jruby program raises unexpectedly and gives me a stack trace, it is nearly incomprehensible. It's full of lines apparently from internal interpreter things, and makes it very hard for me to figure out what the actual call stack of my actual program was.

Things like (just an excerpt):

    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'

And it's not just like these are interspersed with call stack lines from my actual program -- my actual program's call stack does not seem to appear in the stack trace at all. Making it not so useful for it's intended purpose of helping me figure out what actually raised the exception.

I think I remember at some point in the past figuring out some command line arguments to give jruby, related to debugging or JIT or something, that would result in a sane reasonable stack trace again (possibly at the cost of JIT performance or something?).

But trying to find this again, I'm having no luck, spent quite a bit of time trying to find jruby docs, googling, etc., no luck in finding any command line args that result in a reasonable stack trace.

Anyone know?

Answer 1

I will often force compilation of the code with jruby.compile.mode=FORCE, as the compiled code will have the Ruby names and line numbers in the stack traces. This makes things generally slower, so I don't leave it on all the time.

As of JRuby 1.7.10, try setting jruby.rewrite.java.trace to true.

EDIT

From that same Twitter discussion, another idea is to use

rescue NativeException
  raise
end

Which might also help. Of course, you have to know about where the exception occurs, but it should help in a pinch.