There is a similar question for address sanitizers, but for thread sanitizers, it doesn't work, I have tried to break on __sanitizer_print_stack_trace, which doesn't work either.
Run the program under GDB, set breakpoints on exit and _exit. On Linux, also set catch syscall exit_group.
set halt_on_error=1 in TSAN_OPTIONS to ask thread sanitizer to exit on first error:
(gdb) set env TSAN_OPTIONS=halt_on_error=1
(gdb) run
... error should be reported and one of the breakpoints should fire.
Profit.
P.S. When the breakpoint is hit, use GDB where command to see how the error is reported. Setting a breakpoint on some kind of __tsan_report_error that is likely on the stack will probably work even without setting halt_on_error.
The first time I enabled Thread Sanitizer on my project, Xcode helpfully added a breakpoint for me in the Breakpoint Navigator. But I deleted it when I was done testing. Now I need it again and Xcode didn't create it for me when I enabled Thread Sanitizer again.
Note that I am using Xcode 11.0 here.
To manually re-create this breakpoint, you need to have the Breakpoint Navigator open. Then click the plus button (+) at the bottom-left of the navigator and select Runtime Issue Breakpoint from the pop-up menu. This adds the breakpoint to the navigator, and a window appears.
From the Type drop-down list, select Thread Sanitizer.
There you go! Silly that this option is buried way down there. But I also found it helpful to note that there are more options for different kinds of breakpoints available from that plus button menu than there are from the main Xcode drop-down menu Debug > Breakpoints.
Related
I am using gdb 7.7.1 on ubuntu, GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1.
My terminal is Konsole 2.13.2.
The problem I am having is, when I go to the TUI mode, after one or two debugger sessions - session, I mean, set breakpoint, run, step over a while and finally kill it by "kill" command - the output starts messed up. Supposedly each output should go to a new line, but now they just all scramble, one immediately after another one.
I attach a screenshot.
I have to quit GDB, open a new terminal tab and start gdb again.
I tried "ctrl-x-a" back and forth, does not help; neither does "ctrl-l".
A while back, I was using another terminal, it also had this problem.
Any help is appreciated.
It appears that your tty settings changed, in much the same way that tty -onlcr might change them (tty onlcr restores the default). Perhaps the code you're debugging changes tty settings, and doesn't get a chance to restore them because of a crash.
As suggested in a comment, using a separate window might provide a workaround.
I am using Code::Blocks IDE which is open source IDE providing multiple languages.
It is using GCC compiler.
I want to do line by line debugging of program.
Have you any about that?
You can use the "Step Into" command in the "Debug" menu which should start debugging and stop at the first line. Then continue through using the "Next Line" command (also in the "Debug" menu).
If that doesn't work as intended, you can set a breakpoint (by clicking in the left 'gutter', or 'margin') at the first line of your app, and start the debugger from the "Debug" menu, and then use the "Next Line" command in the "Debug" menu.
The shortcut keys vary based on your settings but should be listed alongside the menu command, and makes 'step'ping easier.
Since you're using gcc to compile, you can specify the -g parameter to include debugging symbols, and invoke gdb from the a command shell with the compiled binary as an argument: gdb <yourapp>.
(If [n]curses is installed, specify -tui for a more pleasing interface: gdb -tui <yourapp>.
Once in gdb, the command start will start debugging and stop automatically at main(). You can then step thru with the step command, and quit to exit.
You can always man gdb...
GCC's optimization sometimes makes debugging not easy. To improve your debugging experience, make sure you set optimization to off or to a low level via -O0 or -O1.
Additionally, make sure you have all debug information included in the binary: -g3.
Please go through these steps below:
At first click on debug Menu bar : (Debug-> Debugging windows-> Watches). Now your debugging window is on and the window will be shown at the left corner.
Add breakpoint just clicking left portion of the mouse at those lines you want to debug or test.
Again click on (Debug-> start/continue) It will show a console window. Put input on it. Now press Enter button.
Click on (Debug-> Next line) or press F7 for line by line debugging.
Happpy Coding !
I am using GUD in Emacs to debug C++ program. I setup some breakpoints, and the program stopped. How could I get the number of that breakpoint which triggered the STOP.
So I can apply commands on it. Such as disable the breakpoint temporally.
Thanks
I am debugging an application and for some reason (which I'm not quite sure), when closing my application abort() is called. I'd like to try and find the reason for this, so I want to place a breakpoint on abort() so I can see the stack trace and hopefully discover the reason it was called instead of a graceful exit.
I am using Microsoft Visual Studio 2012 (Update 3) and only have the declaration for the abort() function (in stdlib.h) and so I can't set a breakpoint. Is there any way to get around this?
You don't need to do anything special. abort call from C/C++ program built by Visual Studio produces the following message:
---------------------------
Microsoft Visual C++ Debug Library
---------------------------
Debug Error!
Program: ...
R6010
- abort() has been called
(Press Retry to debug the application)
---------------------------
Abort Retry Ignore
---------------------------
Pressing Retry opens debugger with full call stack. This functionality is available both for Debug and Release configurations, when program runs in standalone mode and under debugger. In Release configuration the dialog is different, it contains Break button, which opens debugger, like Retry in Debug configuration.
I had the same problem and found this answer which works for me: Press CTRL+B and enter 'abort' in the text field.
Just for debug, you may overrides abort function and set a breakpoint inside.
void abort()
{
std::cout << "aborting" << std::endl; // put break here...
exit(-1);
}
In case of linux gdb, upon hitting abort, you could see easily stack trace with command bt. No need to add extra break point.
As mentioned in the title, I am using NetBeans IDE 7.0.1 for C++ (for the assignments at the university). I was using gedit and terminal, but I would like to try my hand at IDEs.
I tried Eclipse but I seem to prefer Netbeans interface.
(All the above->with my laptop, running Ubuntu 11.10).
Well, I have some questions,
Is there any way to "enrich" the "RUN FAILED (exit value 1, total time: 470ms)" message with a "Segmentation fault", as well? (or this is how the IDEs work, run and if you get a "run failed" go to debug mode?)
Also, at debug mode, when I get a segmentation fault I get a new window saying "Signal Caught" and then this:
Signal received: SIGSEGV (?) with sigcode ? (?)
From process: ?
For program testing_netbeans, pid 15,211
You may discard the signal or forward it and you may continue or pause the process
To control which signals are caught or ignored use Debug->Dbx Configure
with three options available ("Discard and Pause", "Discard and Continue", "Forward and Continue"). What do each of the above options do?
How is it possible to get the line where the error occurs? (in example with gdb I would compile with -g3 option and then run with gdb. But now how can I do that by default?
What I did like about eclipse is the fact that it would have a default breakpoint at the 1st line of the main function, is there any way to do that by default?
Thank you for your time!
The compiler flag is -ggdb. It allows you to use breakpoints, know the values of variables and etc.
If you are just building in "debug mode", you will get minimal information, such as line of crash by opening the "call stack" page.
Eclipse is a bit better for debugging, but as an editor, I much prefer Netbeans over it for C++, while I prefer Eclipse for Java
EDIT: Also, you have to have setupped GDB as the debugger in Netbeans, but I'm pretty that's done by default.