Tool to clearly visualize Memory Layout of a C Program

Question

Suppose I am having this code:

int main() {
    int var1;  
    char *ptr = malloc(5 * sizeof(char));  
    //...........  
    do_something();  
    //...........    
    return 0;  
}

We know that the actual memory layout will be divided into segments like: .text, .bss, .data, .heap, .stack.

I know how to use objdump, readelf, etc. But, I want to get a better view of the memory stack, where I can see things like:

.heap       ptr  
.stack      do_something()  
.text       main()  
.bss        var1  

The main point is: The actual variable names are missing from the output of objdump, readelf etc.

I am compiling this code with -g, thus retaining the symbol table.

Then, why am I not able to see the memory layout with local/global variable names included?

objdump -x shows the names of the variables if type is static otherwise not. Why?

Workmanlike

ptr is a local variable of main, just like var1. The object you'd like to see in .heap is a nameless block allocated by a call to malloc, and that block doesn't know that its address was stored in a variable named ptr. This is just one of the reasons you do not really want to see these things in that level of detail. – Jinn

The "-g" is meaningless unless you tell us which compiler you're using. There are general principles for which block each item will appear in (e.g. static variables either in .data or .bss - the ones in .bss don't have initial values) but anything more than that will be defined by the platform and compiler. In fact, even the .data and .bss bit above isn't guaranteed - it's an assumption based on fairly reliable principles, but which may be wrong in some special cases - e.g. there have been C interpreters available in the past. – Tenuis

Oh - and you don't get .heap or .stack sections in object files/assembler/whatever. The heap and the stack are dynamic data structures, the stack managed by the processor (and to some degree the O/S), and the heap managed by the runtime library (and to some degree the O/S). So the compiler simply cannot give you a fixed layout for these - no fixed layout exists. For the stack, it's possible to generate a layout for the locals in a particular function, but with modern compilers it would be more confusing than instructive - there are complications involving scope and register usage. – Tenuis

Thanks Steve, yes we can't get a fixed view of stack & heap sections, but it may still be possible to get an instantaneous view. I am using gcc on GNU/Linux platform. – Workmanlike

if you want the view at some point in time during execution, the best you'll get is probably from a debugger - and they don't focus on providing memory layout visualisations, so don't expect everything to instantly become clear. Anyway, if you're using GCC, that basically means GDB, but that's a command-line tool - not very friendly, and the information you need to see always seems to be the information that just scrolled out of view - so you probably want one of the many GUI tools based on GDB. I have no real experience of those, sorry. – Tenuis

Answer 1

There are few methods to track memory allocation but none of them is a builtin method and all of them require some additional work on your side. In order to visualise memory you will have to use code instrumentation and/or event logging i.e. memory allocation and deallocation events and then replay all the events and generate graphs out of it.

Take a look at this paper:Visualizing Dynamic Memory Allocations (in C programs).

The GCSpy (for heap visualisation) is available here: https://www.cs.kent.ac.uk/projects/gc/gcspy/. While initially used for JVM, you can visualise the heap of a C program using for instance dlmalloc.

I completely understand why you would like to do that - I was looking for the same thing. While I don't find memory layout snapshotting very useful per se, I find observing how memory is being allocated over time very interesting and useful for debugging performance issues.

I remember that XCode had some instrumentation tools built in - never used them though, but perhaps worth exploring what they are offering.

Gough

The paper refers to a broken link unfortunately. – Reckoner

Answer 2

Sorry to say you're a bit confused about this. Consider:

• all your functions go in the .text section
• all your non-static local variables on on the stack: that they may be pointers and you intend to assign them a value returned from malloc doesn't put them on the heap, it just attempts to create a pointed-to object on the heap. No static tool looking at the binary (such as objdump, readelf) can know whether malloc will return memory or fail.
• your global and static variables are likely to end up in an initialised or uninitialised data segment - which depends on whether the initial bit pattern is entirely 0s, and whether the compiler can convince itself of that at compile time.

Further, if you understand the above, then you don't need anything to draw you a little chart on a variable by variable basis, you just know instantly what type of memory you're using.

Briefing

Thanks for the quick reply. I agree with you that I may know what kind of memory I am using. But I was asking this question from Analysis/Debugging point of view, something like: I don't wanna go with my own opinion. I want to see to believe. While debugging with gdb also, we can figure out what the value of a variable may be, but even then we use: gdb$ p var. I just want to look inside some actual memory allocation table where i can see which function/variable name is under what section; and as the program proceeds & run-time stack changes, i wanna get the changed view again. Is it possible? – Workmanlike

@Sandeep: you can't easily look inside the allocation structures used for the heap (at least with the normal heap implementation) - those are the ones used by new/malloc. They're not meant to be examined by the application. You can look inside the stack frames your program's functions have created for local variables: use frame N to change frame, then info locals to show the variables in that frame. Then there's info variables [regexp] to search amongst globals. Check out the "help" information built into gdb for details - a bit of a pain but you'll need to get comfortable with it. – Briefing

As for seeing things change as the program runs: you might find that easier in a UI environment. I think you'd probably like something like DDD - the data display debugger. It is a front end for gdb, but makes it easier to click your way around the variables, follow pointers, inspect the structures etc.. It's free OSS and should be available in your package manager. – Briefing

@Sandeep - silly question, but if you don't trust your debugger to tell you the right value for a variable (sometimes wise - in the past at least, they could get confused), why do you trust it to tell you the right memory layout? Compared with finding the location of a variable on the stack/heap at some point in time, I'd expect decoding the value to be pretty reliable - the only thing that can really go wrong is determining the data type to decode it as. – Tenuis

Hi Steve, its not at all a silly question. I am not saying that I don't trust my debugger for the values it prints. You are not able to understand the question clearly. I am very much comfortable with gdb (No need for any GUI tool) and most of the unix programming tools. I can show you how to get some (not all) info about the memory use of a running program. But, there must be some command line tool to provide the instantaneous information. – Workmanlike

@Sandeep: you can invoke gdb itself as a command line tool such that it list and prints out the values of various variables then exits. (If you had any idea how much work it takes to make something like gdb you wouldn't casually suggest that other similar tools must be lying around when the functional difference you want is so slight). – Briefing

@Tony, Thanks. But I know very well what gdb is & what it can do. Being a software engineer, I very much appreciate the amount of effort required in developing a tool of this calibre. I just asked whether such a tool exists or not, or is it possible to use a combination of existing tools in some manner, which could lead to more information in this regard. I wouldn't have mind if the answer I received was a gentle 'no'. I am not suggesting anybody to develop a new tool to achieve this cause. Anyways, thanks for your replies. – Workmanlike