Is there any way to easy to debug out what cause my hang on main thread?
when I debug without enable the breakpoint, there's a moment that the tableView will hang for a while, but how to found what cause that?
EDIT
I have upload the thread status when the app is hang, and I click the Pause button. show bellow:
EDIT I have upload the Profile of Instruments, which selected duration is which the screen is hang.
Edit
I have create a root problem question about this.Image download and save to file, Image read from file will cause lock?
You can use Instruments for that. Choose Product / Profile. Choose Time Profiler. Start profiling by pressing Record (the red circle). When the table view hangs, you'll most likely see a change in the graph. Select the region on the graph corresponding to the time when the table view hanged, and see what's being done on the main thread. You can find more info on Instruments on the web.
Another option is to start normal debugging, and then press "Pause" right when the tableView hangs. And then look at the stack trace for the main thread.
Related
Preface: don't ask for sample code. This is not a sample code kind of question. If there is a better stack exchange place to be asking this, I am happy to oblige, but a search revealed no such place, so here I am, humbly looking for help.
So, my application receives data from a websocket to a web worker, and then from the web worker to the main application. The application contains, for example, view updating methods. Sometimes these have bugs, so I use the dev tools to set a breakpoint, as one does!
However, while the breakpoint has "paused" the application, the flow of data has not stopped. And as a background process of the browser itself (ie. out of my control), if these are hitting the same breakpoint, they wait around in a queue for processing. The browser itself creates a backlog of times the breakpoint has been hit.
Consequently, you can disable the breakpoint, click "resume execution", and it will go to the next backlogged time a breakpoint was hit. There's no concept of "that breakpoint doesn't exist anymore" because the breakpoint WAS there when the backlog was created.
Net result: if the breakpoint is hit, say 50 times while debugging, I have to click 50 times before I can actually resume execution of the application.
Can anybody spot something I'm doing wrong or missing? Or is there a hidden feature flag that I can set so that the backlog is not created? Or an obvious "always resume" button that once clicked will just hammer its way through any of the backlogged breakpoints?
Side note: you can't even simply (and quickly) refresh the page, because the "backlog" prevents it.
Or an obvious "always resume" button that once clicked will just hammer its way through any of the backlogged breakpoints?
Long-press the Resume button and select Force script execution. Note: I'm not saying it's obvious, but I think this is what you want.
The Deactivate breakpoints button might work, too.
I am running instruments to analyze memory leaks in my application,
but it does not show any responsible libraries for any allocations:
Neither it shows any methods/variables in stack trace, it just shows this:
Is there any setting that I am missing? It used to show earlier, it has stopped showing these just recently.
Here are a couple screen shots of how I currently have mine configured. Maybe these will help. First thing I would do is check to make sure that within the current scheme, you have your "Profile" Build Configuration set to Debug like in the first image below.
Also, have you tried right clicking on "Responsible Library" header to remove the checkmark and re-add it like in my last screenshot, to give it a virtual smack? I'll keep looking to see if I can find out anything else more helpful.
Close instruments. Make sure spotlight indexes your build artifacts. You can do this manually by running mdimport from the command line. Reopen instruments.
Obviously, make sure your derived data location, etc. is not in spotlight's blacklist. This is controlled by System Preferences.
Instruments relies on Spotlight for a lot of what it does.
In the older version of Xcode, I used to press cmd-shift-Y to get a window (I think it was the debugger) to see where errors were coming from in my iPhone app.
But now, I always see question marks, and can't ever seem to properly track where the error is coming from. How do I do it in the new Xcode?
The screenshot you have posted is thread view of debugger actually. When you get an error you can still hit Cmd+Shift+Y which is a keyboard shortcut to hide/show the debug area. It will pop up in main editor area from bottom.
In the debug area, the top horizontal bar shows the buttons to continue, Step Into, Step Over etc. In this horizontal bar, the last item on right hand side is the function name which was executed the last. You can click on that to see the stack trace and track from what function the error is coming. The function which was executed recently in the trace would be the first item in the list and the main function would be the last in this list.
Hope this helps.
I'm debugging a server process running in Eclipse 3.4.1. There are 20 threads or so, waking up at various interval after sleeping.
I set a breakpoint in one method on one thread, and Eclipse stops there properly. The thread is expanded with a stack trace in the Debug view, and I can use the various buttons to step through. This is all what I expect.
My problem is that it seems like when another running thread wakes up while I am stepping through, it steals the focus in the Debug view. My suspended thread is not selected or expanded anymore (it has a + next to it) and all the buttons are disabled. I have to click back on the suspended thread to continue debugging.
Has anyone seen this before and know any workarounds or settings I could change?
You could suspend the entire Java VM not only the executing thread to get rid of the focus problems.
Select a breakpoint in the breakpoints view and choose "Suspend VM" instead of "Suspend Thread". Under Preferences->Java->Debug you can make "Suspend VM" the default option.
I have had the same problem when debugging Play!Framework 2 applications. What seems to have finally solved it is to uncheck Java -> Monitors in the debug perspective/thread view panel context menu.
If the above does not help you can always disable all your breakpoints once you are debugging where you want to be.
In the Breakpoints view: Ctrl-A, Right click -> Disable
Could you use the option to stop all threads at the breakpoint?
Not sure if this will work (haven't got an Eclipse install to hand to confirm), but there's a debug option that you could try.
Under Run/Debug in the Preferences, there's an option called (something like) Activate debug view when a breakpoint is hit. If you uncheck that option Eclipse won't jump the focus to the debug view. It might also stop individual threads stealing the focus.
I'm using Eclipse 3.4.1, moving my first steps. When I run my project (a server process) a console opens. But for some reasons after a while I can't find it anymore (even if the process is still up). I'd like to find it to be able to see its output and/or kill it.
Is there a place in Eclipse where I can find all running sub-processes?
There is a small button that looks like a monitor in the console panel. It lists all open consoles.
I'm ashamed I didn't find it myself before posting the question, but maybe it will be useful to someone.
If you are talking about "eclipse console", there is only one "console view", but several console instances.
You can browse the different consoles by clicking on the second button from the left in the console view (the one looking like a monitor)
Your console may 'disappear' because another message is displayed in the main console (stdout) process, while your server still runs with the other console instance.
An easier way if you are dealing with lots of processes is to use the Debug view (note: NOT the debug perspective, just the debug 'view' or 'window').
It shows a list of running processes, including processes started with Run instead of Debug. Selecting a process in the Debug view will open the corresponding Console, and visa-versa.
I put the Debug view above the Console view and size it to show just a few lines.