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?
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.
Related
I use a crash reporting feature that allows the user to submit a crash report if the application crashed with an uncaught exception.
After adopting C++20 coroutines entered the application.
If there is an unexpected exception thrown in a coroutine the exception is caught before it is rethrown.
This causes crashreports to not show the stacktrace needed to figure out what happened, but only the stacktrace to the coroutine that rethrew the exception. This basically makes any crash reporting useless.
As far as I could find there is no way to prevent the catching of any exceptions by the coroutine because it is a required part of the design.
Is there a way to improve this I cant see?
I am curious because I found nobody else complaining yet. :->
Edit: To clarify the app is running on Windows, I mean the stacktrace of a minidump that is created at the point of the unhandled exception using: SetUnhandledExceptionFilter + MiniDumpWriteDump
C++ does not have standard stack tracing yet, so there is no nice builtin way to do this.
However, there are ways, which rely on keeping information in the promise objects.
Clang has documentation for some common debugging methods for coroutines.
The best solution we have found is as follows (Windows specific!):
Until now we used SetUnhandledExceptionFilter at the start of the app to set an exceptionfilter function that writes a minidump.
Instead we now use _set_se_translator.
If we want the program to just crash (f.e. if windows is set to write dumps) we set a function which calls std::abort.
If we want to handle it interactively we set a function which asks the user whether to send a minidump, the dump is written as before at this point.
Both cases provide the full callstack in the dump.
The only downside remaining is we cant let the program crash for "normal" exceptions to dump, this was possible before. But the "most important" exceptions (f.e. access violations) work.
In Grafana I am trying to log exactly where the exceptions are thrown. This way in my dashboard I can have a panel that shows me where the different exceptions are thrown.
Printing out the stack trace is of course a possibility, but is it simply often too long and I would like a more neat approach.
Cutting down the log string length isn't intuitively an option, since "exception-paths" have different lengths and to a cut, that makes sense, the lengths need to be the same.
I am currently using serilog, but can't manage a way to do what I want (except from printing the entire stack trace) - therefore I am wondering if anyone else have a better solution?
I am coding in Visual Studio, C#, btw - just for clarification.
A gulp watch task keeps throwing an exception with a stack trace that is limited to 10 frames, so I can't tell where it's originating. I'm guessing this must be configurable somewhere but I can't determine where. I looked in gulp.config.js and in gulp.util.js. I read this report but I think it must be easier than that.
Who knows how to do this?
This might work
gulp.on('err', function(e) {
console.log(e.stack);
});
It's super cute how they make everything completely and utterly useless. A stacktrace that tells you nothing, great, that's really useful ... great idea.
Your fix is to run things "manually" like this
$ node --stack-trace-limit=5000 --stack-size=10000 $(which gulp) ...
When I am debugging broken code, after a while the browser announces that the Flash plugin has crashed, and I can't continue debugging my code. Can I prevent the browser from killing Flash?
I am using Firefox.
Going to the debugger on a breakpoint makes the plugin "freeze". This is intentional, it's a breakpoint after all!
However, from the browsers perspective, the plugin seems to be stuck in some kind of infinite loop. The timeout value varies, my Firefox installation is set to 45 seconds.
To change the timeout value go enter about:config in the url field and look for the setting dom.ipc.plugins.timeoutSecs increase this or set it to -1 to disable the timeout altogether.
When the plugin crashes, it does in fact not so, because the browser is "killing" it, but rather the plugin terminates itself when a fatal error occurs. This is necessary to prevent the browser, or even your entire machine from crashing - there is no way to tell what is going to happen after an error like that. And besides: After the first uncaught error, your program will likely not be able to perform even correct code the way you intended, so you won't do any good by continuing a broken debugging session. So it is not a flaw, it is actually a good thing this happens!
However, you can do some things in order to work more effectively (and make your programs better). The most important I can think of right now are:
Learn to use good object-oriented programming techniques and get acquainted with design patterns, if you haven't already done so.
Take extra care to prevent error conditions from happening (e.g. test if an object is null before accessing its properties, give default values to variables when possible, etc.)
Use proper error handling to gracefully catch errors at runtime.
Use unit tests to thoroughly test your code for errors one piece at a time, before debugging in the browser. Getting to know FlexUnit is a good place to start.
EDIT
I should also have said this: A Debugger is a useful tool for stepping through your code to find the source of an error, such as a variable not being properly initialized, or unexpected return values. It is not helpful when trying to find out what's happening after a fatal error has occurred - which will also not help you to fix the code.
I had this strange problem with stack underflow errors happen only in the release build of Flex Builder project. I looked around the web to find a solution, but while I found some related posts, nothing really helped my out. So here is this question and my solution in the answers so that it may hopefully help other people.
The Problem: I ported a java program (a game) to flex and it works fine in debug mode on Android, the web and Playbook. However, when I build a release version of the game, it crashes. The error reported is 1024, i.e. stack underflow, according to Adobe's documentation.
At first, I thought the problem was limited only to the Playbook, but no, the exact same problem happens at the exact same place on the web browser and Android. From the debugging information I inserted, I discovered that the exception appears to be thrown during the call to another function.
To solve the problem, I broke down the offending function in many individual functions and so narrowed down which precise part of the code what causing problem. This lead me to a few lines of code that had the following call (in a try-catch):
trace(e.getStackTrace())()
Hummm, this apparently was produced by the regex I used to refactor from Java to Actionscript. Removing the extra () solve the problem.
This is the kind of things I wished the compiler would catch instead of letting it fail only at release, when the function containing the offending code is pushed on the stack.