My NS app crashes.
It displays the stack trace - but only about 20 lines or so. and then ...
That's not enough for me to figure out where it's crashing.
How can I get it to display more depth.
Thanks
Alternatively you can use Sidekick, Sidekick install, open debug and check its console messages, it does truncate the log but it lets you copy the full log output.
Related
I'm currently (trying) to develop an app with Worklight Studio 5.0.6 and Dojo (Mobile) 1.8.3. I have a really hard time to to find a proper method for debugging. After waiting 5-10 minutes for the build an deploy-process on the server, an error usually looks like this in the Chrome debugger:
How am I supposed to track down this error in MY source? The whole stack trace consists entirely of Dojo code which generates an absolutely useless error message after 20 abstraction layers.
Seriously, how do you guys handle this in real life? What methods do you use for debugging Dojo-driven apps in the browser?
spyro
For dojo.parse errors, I find it useful to pause the Chrome debugger on all exceptions (the purple icon on your screenshot, should be blue). You usally get more details about the cause of the error, the name of the DOM node being parsed, etc. in the first exception being raised.
RĂ©mi.
Debugging dojo based application should be the same as debugging any javascript application.
Usually I will follow these steps:
add console.log() somewhere in code: this is fast and most of time this is enough.
set breakpoint in debugger: if step 1 is not enough, you can base on error information to set breakpoint before error line, then step in or step out.
comment out recently changes: for some error which is hard to find the error line, for example, parse error in your case, the good way is comment out your recently changes one by one till back to your last working version. Or, return to your last working version, then add code back one by one.
Create a simple application to reproduce the error : if your application is very complicate and it is hard for you to follow above methods, you can try to create a new application which mimics your current application but with simple logics and try to reproduce the error.
Based on experience : Some errors, for example, extra ',' in the end of array which works at chrome and firefox, will report a nonsense error information at IE. Debug these kinds of errors is very difficult, you can base on your experience or do a google search.
Did you provide isDebug: true in your dojoConfig? Also, try to see if the same occurs in other browsers.
Update: I recently discovered that there are issues with Google Chrome and Dojo debugging and I think it has to do with the asynchronous loading of files. As you can see in the provided screenshot of #spyro, the ReferenceError object is blank (which you can notice because of the empty brackets {}). If you want to solve that, reopen the console of Google Chrome, (for example by tapping F12 twice). After reopening the ReferenceError should not be empty anymore and now you can expand that object by using the arrow next to it and get a more detailed message about what failed.
Usually what I do in situations like that is to place a breakpoint inside the error callback (line 3398 in your case) and then look into the error variable ("e").
I am not sure how familiar you are with the Web Inspector, but once you hit the breakpoint open the Web Inspector 'console' and check for the error properties "e.message" and "e.stack" (just type in "e.message " in the console).
Also, during development it is better to avoid Dojo optimization / minification, which greatly improve your debug-ability.
Bottom line is to try to place the breakpoint before the error is thrown.
Where XCode generate error for application crash ?
I'm crazyng ! My application when open second file xib with webview then it crash. But I don't know why ? how can i Know where is error ?
You need to learn how to use the debugger in Xcode.
Run your app under the debugger then instead if simply getting a stack trace Xcode will stop at the line the fault occurs and show you your code and variables. You can then examine the contents of your variables, the call tree, etc. and hunt down the problem.
Once you know the general area of the problem you can place breakpoints to pause your application before the problem occurs and check whether your variables have the values expected etc. Then you can run till the next breakpoint, or step through your code a line at a time.
You can add code, such as NSAssert's and NSLog's to your app to check progress and display information without stopping the run, etc.
It's a process, and some problems will be harder to track down, but you'll get quicker at it with practice.
The Xcode documentation will tell you all about the debugger.
HTH
We have a single page application that randomly crashes the whole browser tab. I observed the memory for more than an hour but it wasn't increasing and everything looks just fine. Than out of a sudden after some more time passes, the tab crashes.
I looked for a crash dump in
C:\Users\cburgdorf\AppData\Local\Google\CrashReports
but the Chrome-last.dmp is totally outdated. Is there any place where I can look for additional information about the crash? Not to mention it's a hard to reproduce beast.
I wonder if I could start Chrome with windbg attached and wait (2 hours or so sigh) for the tab crash. Would that work?
UPDATE
All of you gave good answers and provided valueable advice for bug hunting. In the end I was able to reproduce the bug and get a clear crash dump using the following steps:
1.) windbg.exe -o chrome.exe
2.) reproduce crash
3.) .dump /ma C:\Path\To\A\CrashDump\File.dmp (as Paul pointed out)
4.) end session and load the crash dum with windbg
5.) use !analyze -v to extract valuable information
Once WinDbg breaks in, use this command to create a full crash dump:
.dump /ma C:\Path\To\A\CrashDump\File.dmp
If you want analyze only specific tab, you should follow below steps.
Open Chrome's Task Manager (View Background Pages option in menu).
Right click on grid and activate Process ID column.
And attach windbg to this pid.
Follow the instructions on http://www.chromium.org/for-testers/bug-reporting-guidelines/reporting-crash-bug to report the renderer crash so the Chromium developers can debug it.
Could you try to use firebug in chrome and give me a log?
http://getfirebug.com/wiki/index.php/Command_Line_API
upd. you need launch chrome with debug option.
--enable-logging --v=1
For some reason as soon as I login into my PC, I get this error in Windows 7 Ultimate:
http://i51.tinypic.com/b9go6g.png
Any ideas how to get rid of this error and why is it poppoing up?
Find where this application came from (looking at the contents of files in c:\process and in the control panel will help, if not, you can search for that XXXX thing in the registry using regedit).
Then repair or reinstall it. Or uninstall it completely.
Or, if you're brave enough, debug it. For that you should start looking at the contents of the Windows event log and what Process Monitor(separate, downloadable tool) shows -- see what errors you get there for this process, they may give you some clues. Finally, you may even run it under a debugger (e.g. WinDbg, also separate from Windows and downloadable).
Where does Firefox store the contents (text messages) of the Error Console. The errors, warnings, messages etc. are stored somewhere as Firefox retains them even if the browser is closed and re-opened.
I tried to search the entire profile folder but couldn't find out which file or sqlite DB these error console messages are written to ?
Does anyone have idea about this ?
Thanks in advance.
No, Error Console is cleared if you close Firefox and re-open it.
Error Console isn't tied to a particular browser window, so while Firefox runs, the messages are retained even if you close and open some windows. During the lifetime of the application, the messages are stored in memory (code link).
If you're looking for a way to dump messages that appear in the Error Console to a file, it's possible to do that, but I don't remember off-hand and don't want to look for it unless that's what you're interested in.
[edit The best I could find was this]
[edit] if you indeed see this, are you sure it's just base Firefox? Maybe it's some of the extensions you've installed? (Though it would be weird to implement messages persistence in the Error Console.)