In Eclipse CDT my code does not run in debug mode. I get the following message:
/build/gdb-HnfxP_/gdb-7.10/gdb/cp-support.c:1595: demangler-warning: unable to demangle '_ZdvI7Vector3dESt6vectorIDTdvcvT__EcvT0__EESaIS4_EERKS1_IS2_SaIS2_EERKS1_IS3_SaIS3_EE' (demangler failed with signal 11)
Unable to dump core, use `ulimit -c unlimited' before executing GDB next time.
Using https://d.fuqu.jp/c++filtjs/ I found that the mangled symbol corresponds to
std::vector<decltype (((Vector3)())/((double)())), std::allocator<decltype (((Vector3)())/((double)()))> > operator/<Vector3, double>(std::vector<Vector3, std::allocator<Vector3> > const&, std::vector<double, std::allocator<double> > const&)
Why is this giving me an error and how do I fix it?
I reproduced this failure on gdb-7.10 and can confirm that this is fixed in gdb-7.11 and later. I have not tracked down the exact commit that fixed this failure.
There is nothing that you can do to fix this issue other than upgrade to a later version of GDB.
Related
I'm using Ubuntu and gcc. My application crashes I only have Segmentation fault message in console. (previously Segmentation fault (core dumped) was reported but now it changed to just Segmentation fault).
There are no hints where the problem is so I do not understand how should I fix the problem. I need some hints to find what caused this - ideally complete stack trace or at least object type/method or something like this.
What would be the correct way of troubleshooting such type of problem? (may be compile with some extra flags, run some tools, collect core dump and analyze it somehow?)
You might well need to enable core dumps with
ulimit -c unlimited
Once you have a core dump, you can look at the program state with GDB:
gdb my_prog core
You should then have the same view that you would have had if you'd run the program under GDB until it crashed - you could just do that, rather than collecting the core dump. In particular, it will show you which line caused the segfault, and the state of the call stack at that point.
To get the best debugging view, you should tell the compiler to include debugging symbols (-g) and disable optimisation (-O0).
you can use the gdb tools to help debuging.
run gdb ./your_app_name on terminal if you have the gdb installed and you will see some infomation as follow:
.....
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./gsvod_client...done.
(gdb)
then input "r" to start your app, if it crashed again, you can type 'bt' to see the line where the problem occured.
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.
I'm using gcc on GNU/Linux and the debug-files and headers of libc and libstd++ are installed. But I don't know how to tell gdb to use the source-code of them, especially to debug into libstd++.
The source-code of libstdc++ itself seems to be provided in a complicated structure. I think the directory command is the right choice. I'm using here Debian/Ubuntu and downloaded the source with apt-get source libstdc++6 into my home-directory.
I'm pretty sure I didn't need take special steps for this with Fedora (some years ago). Maybe Fedora was prepared in a special way for this. So I will be glad about general instructions, which fit for every distribution.
Thank you
Update
I figured out, that I need to compile with -D_GLIBCXX_DEBUG in addition to -g, so compile command looks like $ g++ -o test test.cpp -g -D_GLIBCXX_DEBUG.
Furthermore I got warning about missing pretty printers, which I solved as described here:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html#debug.gdb
Now I can debug into libstdc++, but I always got this message:
Breakpoint 1, main () at test.cpp:9
9 string str = "str";
(gdb) s
std::allocator<char>::allocator (this=0x7fffffffe1e0)
at /build/buildd/gcc-4.7-4.7.2/build/x86_64-linux-gnu/libstdc++-v3/include/bits/allocator.h:104
104 /build/buildd/gcc-4.7-4.7.2/build/x86_64-linux-gnu/libstdc++-v3/include/bits/allocator.h: No such file or directory.
(gdb) s
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (
this=0x7fffffffe1c0, __s=0x402930 "str", __a=...)
at /usr/include/c++/4.7/bits/basic_string.tcc:217
217 __s + npos, __a), __a)
I don't need to set the directory in gdb to the my downloaded source (I' think it search through my home-directory). So I thought I need a different command to fix this and found "set substitute-path" and pointed it to /home/username/gcc-4.7-4.7.2/gcc-4.7.2/libstdc++-v3 but I doesn't work. Why does gdb look for allocator.h in the completely wrong place?
First find out the sources from :-
https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/index.html
Later compile libstdc++ with DEBUG_FLAGS set it ON.
Then, try it out to debug with gdb.
I am trying to install MPICH 2 on a 64-bit machine running on Ubuntu 11.04 (Natty Narwhal). I used
sudo apt-get install mpich2
First I was surprised to see that mpd was not installed. On looking up on Google, I saw that Hydra is the new default package manager.
So I tried to run my MPI code. I got the following error.
> -------------------------------------------------------------------------------------------
> [ip-10-99-75-58:02212] [[INVALID],INVALID] ORTE_ERROR_LOG: A
> system-required executable either could not be found or was not
> executable by this user in file
> ../../../../../../orte/mca/ess/singleton/ess_singleton_module.c at
> line 357 [ip-10-99-75-58:02212] [[INVALID],INVALID] ORTE_ERROR_LOG: A
> system-required executable either could not be found or was not
> executable by this user in file
> ../../../../../../orte/mca/ess/singleton/ess_singleton_module.c at
> line 230 [ip-10-99-75-58:02212] [[INVALID],INVALID] ORTE_ERROR_LOG: A
> system-required executable either could not be found or was not
> executable by this user in file ../../../orte/runtime/orte_init.c at
> line 132
> --------------------------------------------------------------------------
> It looks like orte_init failed for some reason; your parallel process
> is likely to abort. There are many reasons that a parallel process
> can fail during orte_init; some of which are due to configuration or
> environment problems. This failure appears to be an internal failure;
> here's some additional information (which may only be relevant to an
> Open MPI developer):
>
> orte_ess_set_name failed --> Returned value A system-required
> executable either could not be found or was not executable by this
> user (-127) instead of ORTE_SUCCESS
> --------------------------------------------------------------------------
> --------------------------------------------------------------------------
> It looks like MPI_INIT failed for some reason; your parallel process
> is likely to abort. There are many reasons that a parallel process
> can fail during MPI_INIT; some of which are due to configuration or
> environment problems. This failure appears to be an internal failure;
> here's some additional information (which may only be relevant to an
> Open MPI developer):
>
> ompi_mpi_init: orte_init failed --> Returned "A system-required
> executable either could not be found or was not executable by this
> user" (-127) instead of "Success" (0)
> --------------------------------------------------------------------------
> *** The MPI_Init() function was called before MPI_INIT was invoked.
> *** This is disallowed by the MPI standard.
> *** Your MPI job will now abort.
> -------------------------------------------------------------------------------------------
First of all, it looks to me as an Open MPI error. But I installed MPICH 2 and not Open MPI.
Secondly, I am at a fix on how to handle this as all help seems to be directed to Open MPI users. Am I missing something?
I have the same problem on Ubuntu 12.04. I find my problem is because I have both open-mpi and mpich2 on my computer. When I compile my program using mpicc, it will be linked to open-mpi not mpich2. To fix this problem, you can use "mpicc.mpich2" to compile your program and then use "mpiexec.mpich2" to execute your code.
Indeed, these error messages are all Open MPI errors. For some reason, you appear to also have a (badly configured?) copy of Open MPI installed somewhere. You can check which particular file you are executing when you type mpiexec by running which mpiexec. I believe that you can compare this with the result of:
dpkg --listfiles mpich2
(or similar) in order to figure out where the MPICH2 package was installed.
I had this happen to me, and I found the issue. Somewhere on your system during startup LD_PRELOAD was set to point to libmpi.so in OpenMPI.
Example:
export LD_PRELOAD=<some_directory>/openmpi/1.4.4/lib/libmpi.so
The result is that MPICH2 fails. Just do 'unset LD_PRELOAD' before running MPICH2 and the issue goes away.
Note that setting LD_PRELOAD to OpenMPI's libmpi.so is actually required sometimes for OpenMPI to work, so unsetting may break OpenMPI for you. Just remember to reset it if you need to use OpenMPI.
I develop and run C++ program in Eclipse CDT on Linux.
The problem is that Eclipse CDT does't show any runtime error message (e.g. segmentation fault) in console, while I can get such error message when running program directly with command line.
Hello
You could try to modify the run configuration like this
tab 'Main' > Application = /bin/sh
tab 'Arguments' > 'Program arguments' = -c "Debug/name_of_executable arg0 arg1 ... 2> /dev/stdout"
(replace "arg0 arg1 ..." with your program arguments, if any)
The eclipse console will output both stdout, stderr and the segmentation fault message (prefixed with "/bin/sh: line 1 ...")
note : I used this solution on an older release of eclipse for which the symptoms are the same.
I would recommend that you use the debugger instead of just running the executable!
I had the same problem when trying to import an existing c++ solution into CDT. I found it a bit odd that Eclipse didn't report anything in case of an segmentation fault. If you use the debugger, it will notify you of the segmentation faults and point you to the correct place in the code.