I want to improve the already good analysis of the PyInstaller issue https://github.com/pyinstaller/pyinstaller/issues/2355. For that I need to either catch all errors or set a specific break point with LLDB.
On GitHub I stated
For starters one would essentially just need a break point that catches all errors and then dump the call stack.
I tried break set -E C++, breakpoint set --selector __cxa_throw: [...] but nope, doesn't stop.
The execution does stop i.e. hit the break point if I do b Get but there are way too many functions this selector affects.
To conclude, how can I make the executable, available at http://frightanic.com/misc/hello-world, stop right when that error at ./src/common/stdpbase.cpp(62) occurs?
--selector specifies a break on an ObjC selector name. So I wouldn't expect that one to work. I don't know how these check macros work, but the one getting tripped says it returns a value in non-debug or stops in the debugger for debug, so I'd be surprised if it throws a C++ exception. The fact that the C++ exception breakpoint isn't getting tripped bears that out. You can specify a class::method to lldb's breakpoint. So you might try:
(lldb) break set -n wxStandardPathsBase::Get
That should narrow the breakpoint down. Of course if you have debug information for the wxwidgets, you should be able to set a file & line breakpoint which will also be more precise.
Related
I'm trying to learn the basics of gdb. I saw that, in gdb's help obscure, there's a line that says:
stop -- There is no 'stop' command
However, entering stop does not do the same thing as entering a nonexistant command - it doesn't print the "undefined command" message. Moreover, it appears to do nothing and output nothing.
Is this "command" there for some sort of backward compatibility reason? If not, why is there a command that doesn't do anything but have a line in the help that asserts that it is not a command? If so, why doesn't it print out at least something back to user indicating that nothing has been done, so that they are not confused if they assumed it does something related to its name? Or does it actually do something?
I feel like there's some sort of obvious-in-hindsight reason behind this weird command, but surprisingly I've found no way I can phrase it to Google such that it comes up with anyone else asking this question. I hope I'm not just being dumb and wasting y'alls' time, but I'm honestly stumped.
help obscure for stop command is indeed a bit obscure. To get more info about it you can read help stop:
(gdb) help stop
There is no `stop' command, but you can set a hook on `stop'.
This allows you to set a list of commands to be run each time execution
of the program stops.
Actually there is stop command but it does nothing. It is intended to be used in gdb hooks. See also hooks documentation:
In addition, a pseudo-command, ‘stop’ exists. Defining (‘hook-stop’)
makes the associated commands execute every time execution stops in
your program: before breakpoint commands are run, displays are
printed, or the stack frame is printed.
I am writing gdb command scripts to simplify the debugging. One of the problems I have
is that I am setting a breakpoint, and I want to disable it afterwards, and only enable it after another breakpoint is hit.
What I want to do is this
$my_break_number = break SomeFile.cpp:231
disable $my_break_number
but unfortunately gdb doesn't work this way. I have read the manual, but I cannot find any information on how to do this. Hopefully there is some information I have missed.
gdb will automatically set a convenience variable $bpnum with the last set breakpoint number.
You can possibly use that after setting a breakpoint to disable it (I haven't tested when a breakpoint is ambiguous and creates multiple breakpoints, I think it will work and disable all breakpoint locations created.)
see: http://sourceware.org/gdb/current/onlinedocs/gdb/Set-Breaks.html#Set-Breaks
if you need to use the breakpoint number from commands, that is probably not what you want, but it works for the question as specified.
It sounds like you may want to use the Python GDB scripting, which gives you a lot better programmatic access to breakpoints than what is possible with "regular" command scripts.
Also info breakpoints gives useful information such as:
number of breakpoint, how many time the breakpoint was hit, address in memory, what function is it in, file and line number of breakpoint
I am getting this error with my c++ code:
http://imageshack.us/photo/my-images/193/vcerror.png/
The only problem is it doesn't point me to where the problem is... I understand the string subscript is out of range but I have no idea where it could be.
I was wondering if there is anyway I am able to find where it is? I have a rough idea so I have put a breakpoint in there but how VC++ does breakpoints is horrible. I step-through but it only shows me the code from the C++ files themselves, not my own code.
So, I step over and the error shows straight away.
How can I track down this problem?
Basically, you need to look at the callstack and have all your symbols setup.
I'm going to take a wild guess and suggest that you may not know how to use the "call stack" window.
In a debug session of your program and no breakpoints set, allow your program to run until it hits the assert dialog. Press "retry" to allow control to be passed to the debugger. Another dialog may pop up to prompt you to "break" or "continue". Select break. You should be broken into the debugger at this point.
Then make sure you can see the call stack and have at least one watch window up.
Debug->Windows->Call Stack.
Debug->Windows->Watch->Watch 1
You can double-click on any item in the call stack window to jump to the exact line of code where execution is expected to return to. (Sometimes the little arrow on the editor window is pointing to the next line of code to run after the previous call returns). Double click on the function line in the call-stack window that is directly below the top call stack line. That's likely std::basic_string::operator. What value is getting passed into this function? If hovering over the variable name doesn't work, add it to the "Watch" window. Also, add a watch for "this" so you can analyze the actual size and capacity of the string.
Double click on the function call in the call-stack below where you are currently at. This should take you to the actual buggy line of code in your program. Add another watch for the string variable and should be able to figure out what went wrong.
The rest is up to you.
I'm assuming this is a standalone EXE project with everything build by the IDE. If it is not, then make sure the PDB files from each binary produced is in the same directory as the corresponding binary. Again, if this is a simple EXE project in Visual Studio, this is automatic. Just to be sure, make sure you "Clean" your build first, then do a complete rebuild. That sometimes fixes debugging kinks.
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 one big problem with using STL, C++ and Visual Studio. When i use some std or stl functions (in debug compilation) a have some errors some like this "Incorrect format specifier".
but my code are too large for "hand searching" for this error. Maybe one know how to get some help with finding error, some like __FILE__ & __LINE__ for assert? Because code of program too large.
Or try & catch my last hope?...
with respect Alex
Since you have the source code for the STL, what I would do is set a breakpoint at the point where the "Incorrect format specifier" string is located. Do a grep (eg find in files) for that string, set a breakpoint at each one, run your program and hope for death. :)
You talk about try/catch, so I assume it's throwing an exception. If you run your app within the debugger, doesn't it break your program at the point where the uncaught exception is thrown?
EDIT: If you could alternately compile on Linux/g++ it would leave behind a core with a backtrace in that case.
Maybe you could do status msgs on the console so that you get an idea where the error happens. You can search in this part more detailed with the same technique. Do this as often as you need.
After that you can debug you program and set breakpoints in the 'problem area' and step through it.
EDIT: If you are able to compile the program on linux, you can simply install and run valgrind memcheck. It should print out all errors with line number.
The attached screenshot makes it clear that you hit a runtime assertion, and even offers the option to go directly to the dbugger. This will take you to the faulty callstack.
This message is the default mode of _CrtDbgReport. With _CrtSetReportHook2, you can run your own code before the error is printed. You might create a minidump, for instance.