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) ...
Related
There is some performance issue if I let my traces around the whole code when releasing?
trace("thank you");
Traces are ignored in release builds so there is no performance penalty.
Yes there is a performance issue if you have traces active
Some compilers have specific compiler options stating something similar to "build release client", these might or might not end up with a build where all trace-comments does not exist [are ignored].
Even if you don't have anything listening to trace-statements and they are running, it will first of all do an extra function-call and checking some if-statements, then after that it will be stored inside a log-file on the computer where it is run.
So, you should find out what compiler you have and if that one automatically removes trace-messages when compiling in "release mode". If not, you have to either ignore the performance loss or find ways to work around it
I've noticed that the jackson API obfuscates an infinite recursion by wrapping, and displaying a "chain" that hints at the recursion, i.e. something along the lines of this:
ArrayList[0]->"fieldX"->"..".
I'm wondering what the advantage of doing this is? I recently had alot of trouble with an infinite recursion bug which would be quite easy to trace if the explicit calls were made available.
I suspect it has to do with the fact that, maybe jackson's introspection of the methods is happening in a separate thread, or is done in a way that loses the explicit stack calls.
Jackson does indeed catch this, since more often than not displaying data structure that causes it is much more useful than raw stack trace. Raw stack trace can show you where things happen, but oftentimes not why they happen.
However: one thing Jackson probably should do is to chain the original exception as root cause, to also allow you to inspect it. Looks like this is not yet done, but it should be very easy to add.
I will go ahead and file RFE for this.
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.
I am looking to do something a little, well interesting I think would be a good word. I was wondering if there was a way to catch the text associated with a stack trace from a build (currently I use ANT to build) using the javac task.
A little history, I am using a CI server, CruiseControl, and want to write an adapter that will catch the stack trace from a failed build, and allow for me to parse out which files caused the build to fail from a javac task call. So for example, if code was checked into a repository that had a method signature from another class in it, but that class was never added to the repository, the javac task would fail with a cannot find symbol exception in the class. I want to be able to read the stack trace to get the class that caused the build failure.
Any ideas on how to do this? I would prefer not to have to just read in the log file and parse it out manually (I feel like there should be a better way) but if there isn't then I can just go that route as well.
First, for terminology: The compiler normally does not throw exceptions (if it does, there likely is a bug in the compiler, or your file system makes problems, or something like this), so there is no stack trace.
What you see when compiling is the compiler output, including any compiler error messages.
Looking at ant's javac task, there seems to be no way to redirect the output somewhere, which means parsing it is only possible by parsing the output of the whole ant run.
You might do better by using the Compiler API (javax.tools) and adding a DiagnosticListener to the compiler run. You would have to wrap this into an ant task yourself, though.