I just fired up totalview on my "hello world" application (c++) and i only get to view the assembly code.
Is there any settings/flags i need to set to view the source code? Menubar->View->Source As->Source does not work for me.
the application im trying to debug is just a cout << "Hello World" application, just to get the debugger up and running.
Lets start with the simple stuff.
Did you compile your application with the '-g' debugging flag? The debugger relies on the compiler to provide it with a symbol table and line number table to map what happens in the executable back to your source code. Without that -g flag (or if you subsequently strip your application) that info won't be present and assembly debugging is the best you can hope for.
If you did compile with -g are the source and the executable all together in the same directory, or if not have they been moved since you compiled them? The compiler only knows the locations of the source and executable at the time they are created, if you move them around then sometimes the debugger won't be able to locate the source code file. In that case you might need to give it some help by defining a source code search path.
Write back here and let me know if -g fixed your problem. If not we can look into the search path and such.
Cheers,
Chris
I realize that Jason94 has almost certainly solved his problem some other way, but I figured I could chime in here to answer this since it is a good question.
For this particular case it would be interesting to know if the program is multi-threaded. TotalView is designed to let you work with multi-threaded programs and it has a characteristic that may be surprising to users. By default it won't always focus you on the thread that hits the breakpoint. So your program might actually have stopped at your second breakpoint in another thread.
Imagine you have 6 threads (we'll number them 0 - 5) and you set a breakpoint in a routine. Thread 0 is the one you are focused on and you hit "go". The program runs and thread 4 hits the breakpoint first. By default the breakpoint will stop the whole process when the breakpoint is hit. In the debugger you might see assembly representing where thread 0 was when thread 4 hit the breakpoint.
You can check the root window or the thread pane to see what the status of the other threads are and you might see that one of them says "B2" (for breakpoint 2). Then you can click on that thread and TotalView will refocus you to that thread and you'll see it sitting at the breakpoint.
Why do we do that? Well, because we think it is confusing/disconcerting to have your focus "ripped away from you" just because another thread hit a breakpoint. So by default we leave the user in control of their thread focus.
There is a preference that you can change which will tell totalview to refocus the process window to the "site of the event". You can set that if you would prefer to have TotalView refocus your attention to the breakpoint, but be aware that as you do that you may be bouncing from one thread to the next.
The other possibility is that TotalView stopped the process for some reason other than a breakpoint being hit. Did the program segfault? Check the status bar at the top of the process window to see what the status of the thread and process are.
Anyway -- just wanted to post this for the record.
Related
I have a Qt GUI program, inside it I could click a button to load/unload many dock widgets.
I have the problem that when I click the button to load/unload dock widgets, the programm crash with saying that
Debug Assertion Failed, Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)
It doesn't happen every time. (Actually very rare to happen.)
And when I check the Windows's event log, it says the application hang with a cross thread dead lock.
But most people online said that the _BLOCK_TYPE_IS_VALID(pHead->nBlockUse) means a memory error.
I just don't what's going on...
It is a very big program by someone else and the bug happens very rarely...
What I could do now to locate the bug?
EDIT:
Hi, I have got the crash dump file, and I have seen that my program stop at a worker thread with the call stack: > ntdll.dll!_NtWaitForMultipleObjects#20() + 0x15 bytes
How could I trace back to the source code that the program actually stop?
That usually means you're trying to access an illegal memory block inside an std container.
To debug this properly, just look at the stack in the Call Stack window, look up the stack until you get to your code, and see why the value is invalid.
It's hard to describe it, but briefly, here is what you should do:
Install Application Verifier and run it.
Ctrl+A, select your executable.
Deselect all tests in the right pane, select only Basic->Heaps.
Ensure you have 'Full heap' enabled and 'Traces' enabled (properties via right click on 'Heaps' item).
Save. You may close Application Verifier now.
Launch WinDBG of proper architecture (the same as your app).
Ctrl+E, select your executable.
The program will be stopped on first instruction, run it using F5
The probability you'll hit the bug will be much higher. You'll also may found memory access issue you were not aware of before. When you hit one of them, the debugger will stop with one of 'Verifier stops' and you'll see the message in console telling you which command you can use to investigate further. Usually you'll be able to see detailed info about the heap using !heap -p -a <address>, including allocation and deallocation stacks.
Remember, that Application Verifier checks are enabled even when Application Verifier application is not started. You need to run Application Verifier, disable the checks and press 'Save' to actually disable them.
Hope this will help, at least a bit. Read more about Application Verifier techniques on the Internet.
I am trying to extract the execution sequence of my program (something like a program counter) with gdb on my local computer (windows x86) and gdbserver on a remote target (arm-linux). The idea I had was to insert breakpoints at "important" lines of my source files (i.e.: at the beginning of a specific function, and more in general before and after a conditional statement) with a high ignore count for each breakpoint, and then check if a breakpoint was hit or not. I was actually able to receive the informations with this method, but there is a problem: the application behavior I am debugging depends on real-time, and this specific method slows down the program execution too much. Do you think I could use some other method with gdb? I stumbled upon tracepoints, wich seems the exact thing I am looking for, but I was not able to find some property like a "hit counter" for them. The gdb version I am currently using is 7.5.
Thanks a lot in advance.
If your program execution must not be slowed down, you will probably need some HW tool. See these:
Keil real time trace
Lauterbach PowerDebug
(probably other similar solutions)
I'm writing a software renderer in g++ under mingw32 in Windows 7, using NetBeans 7 as my IDE.
I've been needing to profile it of late, and this need has reached critical mass now that I'm past laying down the structure. I looked around, and to me this answer shows the most promise in being simultaneously cross-platform and keeping things simple.
The gist of that approach is that possibly the most basic (and in many ways, the most accurate) way to profile/optimise is to simply sample the stack directly every now and then by halting execution... Unfortunately, NetBeans won't pause. So I'm trying to find out how to do this sampling with gdb directly.
I don't know a great deal about gdb. What I can tell from the man pages though, is that you set breakpoints before running your executable. That doesn't help me.
Does anyone know of a simple approach to getting gdb (or other gnu tools) to either:
Sample the stack when I say so (preferable)
Take a whole bunch of samples at random intervals over a given period
...give my stated configuration?
Have you tried simply running your executable in gdb, and then just hitting ^C (Ctrl+C) when you want to interrupt it? That should drop you to gdb's prompt, where you can simply run the where command to see where you are, and then carry on execution with continue.
If you find yourself in a irrelevant thread (e.g. a looping UI thread), use thread, info threads and thread n to go to the correct one, then execute where.
I've read the thread break whenever a file(or class) is entered. And I now understood the basic mechanism how to automatically set breakpoints in the classes. However, the solution that thread provided is focused on .net framework. My problem is how to deal with it in standard C++. We use vc 10 compiler on windows 7 platform.
Besides, we prefer methods which do not need recompile when we rechoose the class which we want to inspect since it is a huge project and recompilation takes a lot of time.
Thanks in advanceļ¼
You can do it from the IDE:
http://blogs.msdn.com/b/habibh/archive/2009/09/10/class-breakpoint-how-to-set-a-breakpoint-on-a-c-class-in-the-visual-studio-debugger.aspx
The answer Emile Cormier gives is a good solution. When I try to add a breakpoint "Stack::* " as the link says, I found there is no red point on the left of code lines until I start debugging the program. After stopping the program, the red points disappear, but the break point window will keep track of every breakpoint and you can turn to the code by double clicking the breakpoint in the breakpoint window.
As far as i know, you can only set memory breakpoints (break whenever the contents of a certain memory address is read/written) and then manual breakpoints (break on a certain line of code).
Your best bet may be to set a breakpoint at the beginning of the function call(s) you want to debug.
I have a bug I am chasing (I think its a deadlock). When I run the code it hangs without the debugger flagging an error, so after a while I try pressing the pause (break all) button. The debugger then reports "The process appears to be deadlocked...". I then can see that all the threads are held up at lines saying EnterCriticalSection except for one which is already inside a critical section. When I look at the thread that is inside the C.S. with the debugger I see a green arrow, accompanied by a tiny blue circle pointing at a line with GetWindowText... as below:
// stuff A
{
GetWindowText(editwin[a].child_window_handle,existing_text,MAX_TEXT_SIZE-1);
}
// stuff B
If I hover the mouse over the green arrow I see the text "this is the next statement to execute when this thread returns from the current function". Now this has stumped me because I don't know if it means that it is stuck inside "stuff A" and is waiting to come back or its stuck inside GetWindowText and has somehow got stuck inside that. The arguments to GetWindowText all look sensible to me. If I click on "step into" I get the message "Unable to step. The process has been soft broken".
EDIT: stuff A is in fact the statement:
if (buf_ptr != NULL)
Usually a green arrow beside a line of code means "this is the next line that would be executed, if not for the fact we're stuck somewhere in a deeper stack frame." However, VS makes it impossible to say for sure based on the info provided so far...
[EDIT - of course, deep knowledge of Win32 can provide a very good guess - see the answer by "mos" for a likely explanation based on the GetWindowText() API's known pitfalls]
As mentioned, what Visual Studio shows you is sometimes misleading. To get a closer view of exactly what is happening you need to turn off some non-helpful "features" that VS enables by default. In Tools -> Options -> Debugging -> General, make sure:
Enable address-level debugging = ON
Enable Just My Code = OFF
Enable Source Server support = ON
This should allow you to:
1) break on / step over / etc the exact instruction that's causing the deadlock
2) see the full stack trace up to that point, regardless of module(s)
3) see source code whenever available, assuming your symbol & source servers are configured correctly
Your problem is that GetWindowText actually sends a message to the other window and waits for it to return. If that window is owned by another thread that is waiting for a critical section, GetWindowText will wait forever.
You're stuck inside GetWindowText, and have created a deadlock.
As the previous responses suggest, your code is stuck inside "Stuff A".
Can I suggest another tool for your tool-belt?
I usually find it much easier to debug native synchronization problems using WinDbg.
just launch your program in WinDbg, point to the correct symbols and all the info will be right there for your investigation using the !locks, !cs and k commands.
If you're new to WinDbg, you'll find that the internet is full with information about it. I recommend reading Advanced Windows Debugging as well.
It's a little bit difficult to start, comparing to the user friendly VS Debugger but every minute you'll invest in learning how to use it will save you hours of debugging further down the road.
Assuming your question is "Is this normal", then yes, the debugger usually shows the statement after the one stuck on a critical section.