I am new to gdb and I am trying to figure out if there is a way to do this:
I have a reference and want to know where all this reference is been used in a core dump heap memory, something like a search for all occurrences of this reference in heap memory. Sorry if this question makes no sense or seems too simple.
So first you need to find out where the memory has been mapped. This can be done with either "info files" or "maintenance info sections". After you have the mappings you can use the gdb find command on each of these mappings. The gdb find command has the following syntax:
find begin-address end-address address-to-search-for
Related
I research an embedded device that use GLIBC 2.25.
When I look at /proc/PID/maps I see under the heap section some anonymous sections ,I understand that sections create when the process use new
I dump those sections with dd and there is there interesting value that I want to understand is that buffer allocated or free, and what is the size of this buffer.
How can I do that please?
You can use the gdb (GNU Debugger) tool to inspect the memory of a running process. You can attach to the process using its PID and use the x command to examine memory at a specific address. You can also use the info proc mapping command to view the memory maps of the process, including the size of the heap. Additionally, you can use the heap command to list heap blocks and the malloc_info command to show detailed information about heap blocks.
You can also use the malloc_stats function to display information about the heap usage such as the number of bytes allocated, the number of bytes free and the number of bytes in use.
You can also use the pmap command to display the memory map of a process, including the heap size. This command is available on some systems and may not be present on others.
It's also worth noting that the /proc/PID/maps file can also give you an idea about the heap section of a process.
Please keep in mind that you need to have the right permission to access the process you want to inspect.
Instead of analyzing the memory from proc, you may want to try following options, limited to your env.
use tools like valgrind if you suspect any kind of leaks or invalid read/writes.
rather than looking at output of dd, attach to running process and inspect memory within process, gives you context to make sense of memory usage.
use logging to dump addresses of allocation/free/read/write. This allows you to build better understanding of memory usage.
You may have to use all of the above options depending upon the complexity of your task.
When using Valgrind Massif in LINUX, I tried to see the massif.out.pid file in real time but it produces this file after Massif finished executing. I want to place breakpoints in the code to watch the effect certain instructions have on the heap as there are only a few points of interest. I know I could rewrite some of the code to manage this but this means influencing the subject code in a way that won't be the final result as well that their is numerous programs I want to do this on. Is there a way to watch points in the code while watching the profiler profile the heap at the same time, so I can distinguish between points of execution?
Apparently there is a tool in Linux that can give real time data, I haven't tried it out but found it after additional google searching. Its called heaptrack and apparently it can track the heap while the program is running:
http://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux
Write sleep(0.5) in the code where you want to see the memory heap usage.
then execute application with heaptrack ./app
and then open the result file with heaptrack_gui app.heaptrack.gz
go to consumed tap and check the memory usage by time line.
Maybe it's a bit late, but massif-visualizer is the tool you looking for :
massif-visualizer
I want to attach a command to a breakpoint that writes a full callstack to a file every time the breakpoint is hit. Since I know that this may hit performance hard, I want to print out the information as condensed as possible. However, the bt command always prints a lot of info, like symbols, line in a file etc.
Is there an alternative to bt that prints out as little as possible while still allowing to reconstruct the call hierarchy after debugging has finished? Like, only printing out the instruction pointers of the functions in the stack?
Regards
Since I know that this may hit performance hard, I want to print out the information as condensed as possible.
It's not printing the information that is slow. The mere fact that you hit a breakpoint will already slow down your program immensely (if the breakpoint is hit often).
Like, only printing out the instruction pointers of the functions in the stack?
You don't need GDB for that. On many platforms the program can obtain this info directly (e.g. from backtrace function) and log it to disk. That is usually at least a 100 times faster than doing it in GDB.
the bt command always prints a lot of info, like symbols, line in a file etc.
You can control exactly what is printed with a Python unwinder or frame decorator.
You can remove all debug info from the binary you are debugging using strip tool.
bt should work fast on binary without symbols, you will not get any line numbers or function names, only raw memory addresses in bt output. If you are going to set breakpoint you will have to set it on memory address as there is no debug info anymore in binary.
To reconstruct the call hierarchy after debugging has finished you can use addr2line, see this question: How to use addr2line command in linux. I don't know automated way of resolving all addresses in bt output. Probably you will have to resolve them one by one or write a script to do it automatically. Note that now the binary should be unstripped (with debug symbols).
I am trying to improve the performance of my C++ program and I found that converting memory allocations (mallocs) into object pool is giving great results.
The problem is detecting the places from which malloc is called, since the code base is quite large. I can't use simple gdb with break points because there are many timers and signal handlers running in parallel.
Is there a way in gdb using which I can print the entire stack trace whenever malloc is called without having to do it manually each time.
OR
Can you suggest any other tool which will help me do the same.
You can script gdb using Python.
You can also implement your own malloc function and link with that. The return address will be on the stack, which will give you the caller.
The valgrind suite of tools contains massif which you can use for precisely this purpose:
valgrind --tool=massif ./mybinary
This collects details of all allocations including stack traces that you can examine after the program has finished executing. Please see the massif documentation for more details on the output: http://valgrind.org/docs/manual/ms-manual.html. Hope that helps.
P.S. Also checkout the TCMalloc library - it already possibly already does what you want, although you can do better depending on your specific application. The best thing is that no source code changes are needed - you simply replace the malloc function from glibc using a linker directive.
I'm debugging an application and it segfaults at a position where it is almost impossible to determine which of the many instances causes the segfault.
I figured that if I'm able to resolve the position at which the object is created, I will know which instance is causing the problem and resolve the bug.
To be able to retrieve this information, gdb (or some other application) would of course have to override the default malloc/new/new[] implementations, but instrumenting my application with this would be alright.
One could argue that I could just put a breakpoint on the line before the one that segfaults and step into the object from there, but the problem is that this is a central message dispatcher loop which handles a lot of different messages and I'm not able to set a breakpoint condition in such a way as to trap my misbehaving object.
So, at the point where the segfault occurs, you have the object, but you don't know which of many pieces of code that create such objects created it, right?
I'd instrument all of those object-creation bits and have them log the address of each object created to a file, along with the file and line number (the __LINE__ and __FILE__ pre-defined macros can help make this easy).
Then run the app under the debugger, let it trap the segfault and look the address of the offending object up in your log to find out where it was created. Then peel the next layer of the onion.
Have you tried using a memory debugging library (e.g. dmalloc). Many of these already instrument new, etc. and records where an allocation is made. Some are easier to access from gdb than others though.
This product has a memory debugging feature that does what you want: http://www.allinea.com/index.php?page=48
I would first try using the backtrace command in gdb when the segfault occurs. If that does not give me a good clue about what is going on, I would next try to use valgrind to check if there are any memory leaks occurring. These two steps are usually sufficient, in my experience, to narrow down and find the problem spot in most of the usual cases.
Regards.