I am fairly new to GDB and V8 JavaScript engine.
After compiling shell.cc(/v8/v8-trunk/samples/Shell.cc), I try to set the breakpoint(b Parser::Parser) in parser.cc(/v8/v8-trunk/src), then GDB unexpectedly displays an error message: Can't find member of namespace, class, struct, or union named "Parser::Parser". However, the source code of the method "Parser::Parser" can be found in parser.cc.
Any ideas? thanks.
(gdb) c
Continuing.
V8 version 3.13.1 [sample shell]
> 3+5;
8
>
Program received signal SIGINT, Interrupt.
0x00752402 in __kernel_vsyscall ()
(gdb) b Parser::Parser
Can't find member of namespace, class, struct, or union named "Parser::Parser"
Hint: try 'Parser::Parser<TAB> or 'Parser::Parser<ESC-?>
(Note leading single quote.)
(gdb)
You need to specify namespaces also. According to parser.cc, Parser::Parser is located inside v8::internal namespace. Try this:
(gdb) b 'v8::internal::Parser::Parser'
Related
I wish to test in my program below: when s="abc", break inside "f()" and see the value if "i".
#include<string>
using namespace std;
int i=0;
void f(const string& s1)
{
++i; // line 6
}
int main()
{
string s="a";
s+="b";
s+="c";
s+="d";
s+="e";
s+="f";
return 0;
}
Compile and run a.out, no problem. I then debug it
g++ 1.cpp -g
gdb a.out
...
(gdb) b main if strcmp(s.c_str(),"abc")==0
Breakpoint 1 at 0x400979: file 1.cpp, line 9.
(gdb) r
Starting program: /home/dev/a.out
Program received signal SIGSEGV, Segmentation fault.
__strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
31 ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: No such file or directory.
Error in testing breakpoint condition:
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(__strcmp_sse2_unaligned) will be abandoned.
When the function is done executing, GDB will silently stop.
Program received signal SIGSEGV, Segmentation fault.
Breakpoint 1, __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
31 in ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S
If I change the break point declaration into:
(gdb) b main:6 if s.compare("abc")==0
Breakpoint 1 at 0x400979: file 1.cpp, line 9.
Then I get another kind of crash, seems:
(gdb) r
Starting program: /home/dev/a.out
Program received signal SIGSEGV, Segmentation fault.
__memcmp_sse4_1 () at ../sysdeps/x86_64/multiarch/memcmp-sse4.S:1024
1024 ../sysdeps/x86_64/multiarch/memcmp-sse4.S: No such file or directory.
Error in testing breakpoint condition:
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::compare(char const*) const) will be abandoned.
When the function is done executing, GDB will silently stop.
Program received signal SIGSEGV, Segmentation fault.
Breakpoint 1, __memcmp_sse4_1 () at ../sysdeps/x86_64/multiarch/memcmp-sse4.S:1024
1024 in ../sysdeps/x86_64/multiarch/memcmp-sse4.S
Is this crash caused by gdb, or my command? If my command has runtime problem, why gdb doesn't simply report an error, by rather crash the program?
Hope to get some explanations, as I didn't get this error cause.
What is going on here is that your command:
(gdb) break main:6
... is interpreted by gdb as the same as break main. You can see this by typing the latter as well:
(gdb) b main:6
Breakpoint 1 at 0x400919: file q.cc, line 10.
(gdb) b main
Note: breakpoint 1 also set at pc 0x400919.
Breakpoint 2 at 0x400919: file q.cc, line 10.
Now, this is peculiar because gdb presumably ought to warn you that the trailing :6 is ignored. (I'd recommend filing a bug asking that this be made a syntax error.)
If you want to break at a certain line in a file you must use the source file name. Presumably you meant to type:
(gdb) break main.cc:6
I'm using assert from <cassert> to check invariants in my multithreaded C++11 program. When the assertion fails, I'd like to be able to inspect the state of the failing function, along with still-intact backtrace, variable state, etc. at the time of the failed assertion. The issue seems be some interaction between SIGABRT and my threads, as my std::threads are pthread_killed, presumably by some default signal handler. How can I pause gdb right at the time of the failed assertion?
Here are some things I've tried:
set a catchpoint on SIGABRT. This catch does occur, but it's too late (in __pthread_kill).
defined __assert_fail, which is extern declared in <assert.h>, and set a gdb breakpoint on it. This is never caught so presumably the pthread is being killed before this is called (?).
What's the recommended approach here?
I did the following:
Example programm:
#include <cassert>
void f2()
{
assert(0);
}
void f1()
{
f2();
}
int main()
{
f1();
}
Now I set a breakpoint to f2 in hope I can step down to the assert with stepi later:
gdb > break f2
gdb > run
Breakpoint 11, f2 () at main.cpp:5
gdb > stepi // several times!!!!
0x080484b0 in __assert_fail#plt ()
Ahhh! As we can see stepi goes to symbol which tells us that there is a function with that name. So set simply a breakpoint for __assert_fail#plt
gdb > break __assert_fail#plt
gdb > run
Breakpoint 11, f2 () at main.cpp:5
(gdb) bt
#0 0x080484b0 in __assert_fail#plt ()
#1 0x080485f7 in f2 () at main.cpp:5
#2 0x08048602 in f1 () at main.cpp:10
#3 0x0804861b in main () at main.cpp:15
Works for me!
If you need a breakpoint on assert for some reason, Klaus's answer to break on __assert_fail is absolutely correct.
However, it turns out that setting a breakpoint to see stack traces in gdb on multithreaded programs is simply not necessary at all, as gdb already breaks on SIGABRT and switches the the aborting thread. In my case I had a misconfigured set of libraries that lead to this red herring. If you are trying to see stack traces from aborted code (SIGABRT) in gdb using multithreaded programs, you do not need to do anything in gdb, assuming the default signal handlers are in place.
FYI, you can see the default signal handlers by running info signals, and the same for just SIGABRT by running info signals SIGABRT. On my machine, I see this, which shows that the program will be stopped, etc. If for some reason your SIGABRT signal handler is not set up to stop on SIGABRT, you need to change that setting. More info at https://sourceware.org/gdb/onlinedocs/gdb/Signals.html.
(gdb) info signals SIGABRT
Signal Stop Print Pass to program Description
SIGABRT Yes Yes Yes Aborted
I´m new to C++ programing. I am compiling a Windows Application which compiles ok with just a few warnings, but when I launch it, it doesn´t even seem to start and returns an Access Violation 3 seconds into the run. When I try to debug it doesn´t even seem to get into the code, so I don´t know where to start looking for the problem.
Here is the info I have been able to retrieve from the debugger:
Building to ensure sources are up-to-date
Build succeeded
Selecting target:
Debug
Adding source dir: C:\Documents and Settings\Christian Ekiza\Mis documentos\My Dropbox\Private Files\coding\juego_pruebas_01\juego_pruebas_01\
Adding source dir: C:\Documents and Settings\Christian Ekiza\Mis documentos\My Dropbox\Private Files\coding\juego_pruebas_01\juego_pruebas_01\
Adding file: bin\Debug\juego_pruebas_01.exe
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 6.8
Child process PID: 3328
Program received signal SIGSEGV, Segmentation fault.
In ?? () ()
and this is from the Call Stack
#0 00000000 0x000154e4 in ??() (??:??)
#1 00409198 __cmshared_create_or_grab() (../../../../gcc-4.4.1/libgcc/../gcc/config/i386/cygming-shared-data.c:140)
#2 00000000 0x0040131b in __gcc_register_frame() (??:??)
#3 00000000 0x0040a09b in register_frame_ctor() (??:??)
#4 00000000 0x00408f42 in __do_global_ctors() (??:??)
#5 00000000 0x00401095 in __mingw_CRTStartup() (??:??)
#6 00000000 0x00401148 in mainCRTStartup() (??:??)
And the CPU Registers end with a
'gs' register with a hex value '0x0'
I don't really know where to start looking for the problem. Anyone can help me out or point me in the right direction?
Note: I am using Code::Blocks
As you say it is a Windows application. Then, any issues with startup, I have found ADPlus very useful.
EDIT 2:
You may also check User Mode Process Dumper if ADPlus does not apply
See, if you have some global instance(s) of class with constructor - if error is raised in constructor and class is declared globally (bad thing to do btw) - you'll get sigsegv even before main().
If you have such classes - try to refactor your code to have them inside main (or other function) - it will be easier to debug.
Try the following free MS tools - both are great for debugging this kind of problem.
Application Verifier http://www.microsoft.com/downloads/en/details.aspx?familyid=c4a25ab9-649d-4a1b-b4a7-c9d8b095df18&displaylang=en
Gflags from Debugging Tools for Windows http://www.microsoft.com/downloads/en/details.aspx?FamilyID=6b6c21d2-2006-4afa-9702-529fa782d63b&displaylang=en
Sounds to me like one of your DLL dependencies can't be loaded or instantiated correctly.
Did you you compile with debug mode (-g) enabled?
Also seriously consider actually fixing the warnings. Most of the time they are actual problems in the code that should be resolved.
You should also try to see if this happens with a nearly empty main (comment out most/all of your code in main).
I've got a protected object that presents functions and procedures in its interface.
In gdb, when I set a bp on the first line of one of those, I get odd results.
Here's a snippet from my gdb console:
(gdb)
(gdb) b database-access_manager.adb:20001
Breakpoint 3 at 0x1a10588: file y:/svs/central_switch/controller/database/
database-access_manager.ads, line 20001.
(gdb)
You can see that gdb is confused. I specified a bp at 20001 of the .adb file but gdb responded by saying it had set the bp at 20001 of the corresponding ads file - which doesn't have that many lines.
What gives?
That .ads file wouldn't happen to be defining or using a generic, would it?
I have yet to find a debugger that handles Ada generics very well. The compiler often creates a raft of semi-invisible code that confuses the heck out of debuggers. I suspect C++ templates have the same issue.
Another possibility is that you are looking at a source file that has been modified since your program was compiled.
Running on Windows with GNAT Pro 6.3.1 (I realise this isn't an ideal data point for you!) this worked fine.
I did notice that when I requested a bp on the subprogram specification, GDB effectively set two bps, one in the specification and one at the first statement: so, given
package body Protected_Object is
protected body PO is
procedure Put (V : Integer) is
begin
Value := V;
end Put;
function Get return Integer is
begin
return Value;
end Get;
end PO;
end Protected_Object;
the GDB console says (for Put)
gdb) break protected_object.adb:4
Breakpoint 1 at 0x401729: file protected_object.adb, line 6. (2 locations)
and at run time, sure enough there are 2 breaks:
Breakpoint 1, <protected_object__po__putP> (<_object>=..., v=42) at protected_object.adb:4
(gdb) cont
Breakpoint 1, protected_object.po.put (<_object>=..., v=42) at protected_object.adb:6
Version: GNU gdb (GDB) 7.0.1 for GNAT Pro 6.3.1 (20100112) [rev:158983]
Here's the update on my problem.
I made a protected type with access methods and used it in a small main and found that breakpoints in my example protected type worked fine.
Now I'm trying to understand why, within the context of my company's very large build, the breakpoints don't work.
I'm using the same gdb, GPS, & compiler switches in each case and it works for the small program but not in the large one.
I'll post my results when/if I have any.
Thanks to all the repliers.
Tom
I'd like to go through a binary file my teacher gave me line by line to check addresses on the stack and the contents of different registers, but I'm not extremely familiar with using gdb. Although I have the C code, we're supposed to work entirely from a binary file. Here are the commands I've used so far:
(gdb) file SomeCode
Which gives me this message:
Reading symbols from ../overflow/SomeCode ...(no debugging symbols found)...done.
Then I use :
(gdb) disas main
which gives me all of the assembly. I wanted to set up a break point and use the "next" command, but none of the commands I tried work. Does anyone know the syntax I would use?
try using ni which is nexti. equivalent is si which is step instruction
nexti if you want to jump over function calls.
stepi if you want to enter a function call.
The following documentation is very helpful; it has a list of all the important commands you could use on gdb.
X86-64: http://csapp.cs.cmu.edu/public/docs/gdbnotes-x86-64.pdf
IA32: http://csapp.cs.cmu.edu/public/docs/gdbnotes-ia32.pdf