I'm using vscode on Windows, and use mingw-w64 as compiler. my test code are as follows:
vector<string> words = {"SEND", "MORE"};
string result = "MONEY";
when I debug it, I can print 'words' and 'result' object correctly, but when I try to use subscript, something wrong occured:
print words[0] // gdb: Could not find operator[].
and more seriously, when I try print string's subscript, gdb just crashed:
print result[0]
// ERROR: GDB exited unexpectedly with exit code -1073741819 (0xC0000005). Debugging will now abort.
Those errors occurred samely whether debug with vscode or use gdb in cmd shell manually.
However, when I debug on linux platform using gdb, it works perfectly. That makes me confusing. I can't find if there's any bug in mingw, or maybe gdb doesn't support windows platform well. My g++ and gdb version are 8.1.0. I have tried some older version but all those have same problems. Is there any good solution, or shall I just give it up?
Clean your path environment and PY_HOME.
Related
I am using Codeblocks for the first time to run a cpp program. While compling the program an error occurs, I want to know the line number from the program where the error is evoking or in other words I want to see the stack trace of the program.
How can achieve this?
You can also use gdb. To debug, compile with g++ and -g at the end of the command and then run your program with gdb (in linux, gdb ./NameOfYourProgram). Then, you type r to run it, and when an error occurs, just type where and you get the stack. You can also set breakpoints and perform steps with gdb to examine the bug further.
Is there any gcc option I can set that will give me the line number of the segmentation fault?
I know I can:
Debug line by line
Put printfs in the code to narrow down.
Edits:
bt / where on gdb give No stack.
Helpful suggestion
I don't know of a gcc option, but you should be able to run the application with gdb and then when it crashes, type where to take a look at the stack when it exited, which should get you close.
$ gdb blah
(gdb) run
(gdb) where
Edit for completeness:
You should also make sure to build the application with debug flags on using the -g gcc option to include line numbers in the executable.
Another option is to use the bt (backtrace) command.
Here's a complete shell/gdb session
$ gcc -ggdb myproj.c
$ gdb a.out
gdb> run --some-option=foo --other-option=bar
(gdb will say your program hit a segfault)
gdb> bt
(gdb prints a stack trace)
gdb> q
[are you sure, your program is still running]? y
$ emacs myproj.c # heh, I know what the error is now...
Happy hacking :-)
You can get gcc to print you a stacktrace when your program gets a SEGV signal, similar to how Java and other friendlier languages handle null pointer exceptions. See my answer here for more details:
how to generate a stacktace when my C++ app crashes ( using gcc compiler )
The nice thing about this is you can just leave it in your code; you don't need to run things through gdb to get the nice debug output.
If you compile with -g and follow the instructions there, you can use a command-line tool like addr2line to get file/line information from the output.
Run it under valgrind.
you also need to build with debug flags on -g
You can also open the core dump with gdb (you need -g though).
If all the preceding suggestions to compile with debugging (-g) and run under a debugger (gdb, run, bt) are not working for you, then:
Elementary: Maybe you're not running under the debugger, you're just trying to analyze the postmortem core dump. (If you start a debug session, but don't run the program, or if it exits, then when you ask for a backtrace, gdb will say "No stack" -- because there's no running program at all. Don't forget to type "run".) If it segfaulted, don't forget to add the third argument (core) when you run gdb, otherwise you start in the same state, not attached to any particular process or memory image.
Difficult: If your program is/was really running but your gdb is saying "No stack" perhaps your stack pointer is badly smashed. In which case, you may be a buffer overflow problem somewhere, severe enough to mash your runtime state entirely. GCC 4.1 supports the ProPolice "Stack Smashing Protector" that is enabled with -fstack-protector-all. It can be added to GCC 3.x with a patch.
There is no method for GCC to provide this information, you'll have to rely on an external program like GDB.
GDB can give you the line where a crash occurred with the "bt" (short for "backtrace") command after the program has seg faulted. This will give you not only the line of the crash, but the whole stack of the program (so you can see what called the function where the crash happened).
The No stack problem seems to happen when the program exit successfully.
For the record, I had this problem because I had forgotten a return in my code, which made my program exit with failure code.
I tried running GDB, version 7.6.50.20130508-cvs (cygwin-special), on Xemacs version 21.4.21 but I get the following error:
/netrel/src/gdb-7.6.50-2/gdb/cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed
A problem internal to GDB has been detected,
further debugging may prove unreliable
GDB by itself works fine on Cygwin. On the Cygwin terminal, I did:
g++ -g -o HelloWorld HelloWorld.cpp
to get the executable, and wrote
gdb HelloWorld.exe
and then
r
and it worked perfectly. I then did
gdb -v
and the version turned out to be the same as the gdb used by xemacs, so it seems that the error must be related to the interaction of gdb and xemacs, instead of it being a gdb problem?
I found that some people had the same, or similar, issue:
http://old.nabble.com/-RFA--dangling-cleanup-in-find_frame_funname-td35521450.html
Any ideas? Thanks in advance!
Also, does anyone know where is the cleanups.c file located? I can't even find the netrel folder (it certainly is not located in the / folder in Cygwin).
instead of it being a gdb problem?
It is a GDB problem (internal assert is failing), and you should report it in GDB bugzilla if you can reproduce it with current HEAD CVS revision.
the error must be related to the interaction of gdb and xemacs
Emacs interacts with GDB in MI mode. But it's still a GDB bug.
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.
I have a large C++ function which uses OpenCV library and running on Windows with cygwin g++ compiler. At the end it gives Aborted(core dumped) but the function runs completely before that. I have also tried to put the print statement in the end of the function. That also gets printed. So I think there is no logical bug in code which will generate the fault.
Please explain.
I am also using assert statements.But the aborted error is not due to assert statement. It does not say that assertion failed. It comes at end only without any message.
Also the file is a part of a large project so I cannot post the code also.
gdb results:
Program received signal SIGABRT, Aborted.
0x7c90e514 in ntdll!LdrAccessResource () from /c/WINDOWS/system32/ntdll.dll
It looks like a memory fault (write to freed memory, double-free, stack overflow,...). When the code can be compiled and run under Linux you can use valgrind to see if there are memory issues. Also you can try to disable parts of the application until the problem disappears, to get a clue where the error happens. But this method can also give false positives, since memory related bugs can cause modules to fail which are not the cause of the error. Also you can run the program in gdb. But also here the position the debugger points to may not be the position where the error happened.
You don't give us much to go on. However, this looks like you are running into some problem when freeing resources. Maybe a heap corruption. Have you tried running it under gdb and then looking where it crashes? Also, check if all your new/delete calls match.
Load the core dump together with the binary into gdb to get an idea at which location the problem list. Command line is:
gdb <path to the binary> <path to the core file>
For more details on gdb see GDB: The GNU Project Debugger.
Run it through AppVerifier and cdb.
E.g.
cdb -xd sov -xd av -xd ch <program> <args>