Im very much confused about the pattern at which memory is allocated in linux system..to understand that i made a simple program which i have listed below :
Output on a Red Hat Linux 7.3 X86 PC:
The address of a : 0xbffffa74
The address of b : 0xbffffa73
The address of c : 0xbffffa6c
The address of p : 0xbffffa68
The address of q : 0xbffffa64
The address of r : 0xbffffa60
The address at which new1 memory is allocated : 0x8050638
The address at which new2 memory is allocated : 0x8050648
The address at which new3 memory is allocated : 0x8050658


Now below are some of my question.Pls help me in understanding..

1.why is there a difference of 7 bytes between c and b on stack?

2.Why is there a difference of 10 bytes for every variable allocated on heap?

3.Whenever i run this executable,i get the same address..how is that possible?

Please help me in understanding this behaviour..

Alignment. c needs 4 bytes, but needs that at an address divisible by 4.

That is an effect of the data structures used by malloc to manage the pool of free memory. It could be different with a different version of malloc. In the version you are using, up to 8 bytes of data can be allocated with 8 bytes of overhead and only on a boundary divisible by 8. So each small allocation takes 0x10 bytes.

I would have expected some effect of address space randomization. I don't know why you don't get that. But why are you surprised at the matching results? All the addresses are virtual and not related to the physical addresses. So if the loader were not randomizing stack and heap addresses (as a method of making some types of malware harder to write) then you should expect reproducible results.

1 members found this post helpful.

> 1.why is there a difference of 7 bytes between c and b on stack?

alignment, most likely

> 2.Why is there a difference of 10 bytes for every variable allocated on heap?

there's administrative data-areas before (sometimes after, too) the actual data

> 3.Whenever i run this executable,i get the same address..how is that possible?

every process runs in a separate address space

The bottom-line is: "whatever it is, don't count on it!"

Focus only upon what your piece of software needs to ask the memory-allocator to provide. Trust that, somehow, it will always (and "efficiently") do it. Never peek at the little man behind the curtain. And, never base your program's actions upon any sort of anticipation with regards to what "the little man" might in any circumstance do.

1 members found this post helpful.

even when there is no memory left, it will do it
(not sarcastic, the kernel is optimistic at giving away pages)

...

"The bottom line," for you as an Application Programmer, is that ... "for you, as an Application Programmer, it is (and must be) Magic."

Sure, it's all being done by The Little Man Behind The Curtain.™ You know that, and we know that, but you must pretend not to care. The cardinal rule of this game is that you must presume nothing about the little man, nor His Magickal Ways. You must not look for "memory allocation patterns." You must use the non-NULL pointer that is given you, or you must swallow NULL as best you can. "And, that's it." Don't look at the pointer-values. Don't question how they were computed nor why they might be different, one from another. If they are NULL, then tough-cookies, and if they are not NULL, "yours is merely but to use them."

"Do not inquire as to the ways of Dragons, for thou art Crunchy, and tasteth good when thou art Broiled ..."

Hi johnsfine & NevemTeve,
Thanks for ur reply...almost clarified my doubts..
As u said,"Alignment".. is that a concept in operating systems? any refernces available? pls share if any..i would like to go through those..

Regarding my doubt on address allocation,i have tried few tricky ways to understand, yet i end up confused..I have listed them..
1.I tried the above program on a CentOS release 5.3,it shows the output as below :
[root@SCUFIN MEMANALYSIS]# ./a.out
The address of a : 0xbfb324e0
The address of b : 0xbfb324df
The address of c : 0xbfb324d8
The address of p : 0xbfb324d4
The address of q : 0xbfb324d0
The address of r : 0xbfb324cc
The address at which new1 memory is allocated : 0x81e9008
The address at which new2 memory is allocated : 0x81e9018
The address at which new3 memory is allocated : 0x81e9028
[root@SCUFIN MEMANALYSIS]# ./a.out
The address of a : 0xbffc9180
The address of b : 0xbffc917f
The address of c : 0xbffc9178
The address of p : 0xbffc9174
The address of q : 0xbffc9170
The address of r : 0xbffc916c
The address at which new1 memory is allocated : 0x9f44008
The address at which new2 memory is allocated : 0x9f44018
The address at which new3 memory is allocated : 0x9f44028

Here the address are not same when executed many times..Waht could be the difference maker?

2.I added sleep(60) next to the last printf statement.Here my intention was to make the process sleep and re-run the same executable in a new shell,which i thought will store the variables in a different memory allocation..But the same addresses got displayed which very much confused me.. how would this be possible for 2 same process occupying same memory addresses(On Red Red Hat Linux 7.3 X86 PC)?

Can you pls share your ideas on these?

Hi sundialsvcs and genss,
Thanks for ur replies .. Right now im debugging a memory related issue where a process uses "new" operator to allocating memory by running in a for loop of 430 iteration.To understand the pattern for both heap and stack memory allocation im tyring to understand the little man's working..

As i said,Right now im debugging a memory related issue where a process uses "new" operator to allocating memory by running in a for loop of 430 iteration,but the process gets hanged rarely when trying to allocate memory around the 400th iteration.. any idea on why would this happen? if its because of no enough memory how could i prove it? Like at the point when the process hangs at "new" how can i understand there is no further memory?Will the stack and heap pointer collide at this point? if so how do i find that? pls share your ideas..

alignment is a cpu/bus thing
memory is divided by 4 bytes on a 32bit system and 8 bytes on a 64bit system
while sse and alikes need 16 byte alignment for most instructions

for example if you write 4 bytes with one byte stride
the cpu has to read 8 bytes, put it together then write them back
what ever the case, aligned memory access is waaaaay faster then unaligned

further more memory is divided into "pages" that are 4kB
bigger pages can also be used, up to i think it was 2MB

pages are how "virtual memory" is managed
virtual memory is a way of giving every process it's own memory space

a process gets memory by calling mmap from the kernel (there is also brk(), but thats...)
mmap gives a minimum of 4kB
it does so by writing into a page table
a page table as the name implies is a table that says how the virtual address translates to a physical one in RAM (in pages, ofc)

ofc this is for x86 and amd64

google about cpu's memory access, virtual adressing and how malloc works
i would recommend writing a malloc to anyone, even thou it can get complicated very fast

PS another interesting thing is that linux is a COW system, making things like fork() very fast indeed
also shared memory is interesting (shm_open, mmaping files etc.)

> any refernces available? pls share if any..i would like to go through those..

eg: https://en.wikipedia.org/wiki/Data_structure_alignment

> Here the address are not same when executed many times..Waht could be the difference maker?

the kernel. This thing is address space randomization https://en.wikipedia.org/wiki/Addres..._randomization

> I added sleep(60) next to the last printf statement.Here my intention was to make the process sleep and re-run the same executable in a new shell,which i thought will store the variables in a different memory allocation..But the same addresses got displayed which very much confused me.. how would this be possible for 2 same process occupying same memory addresses(On Red Red Hat Linux 7.3 X86 PC)?

Please re-read my last answer: every process runs in a separate address space

1 members found this post helpful.

The short-answer is that there is a bug somewhere in your application. It's as simple as that. Really. It has nothing at all to do with the memory allocator.

The nature of your bug is probably a "stale pointer." Either the pointer was not initialized to NULL, or every pointer to some memory-block was not set back to NULL when a block was discarded. (Your application is responsible for doing both of these things.)

In this case, it is a hardware concept and a compiler behavior based on that hardware concept.

Using a 32-bit value (such as an int) is more efficient in the hardware if the address is divisible by 4. A 64-bit value such as a double is more efficient if the address is divisible by 8. Certain advanced operations on arrays of doubles only work at all if the address is divisible by 0x10.

The compiler knows about those first two alignment issues and pads things (wastes some memory) to get the efficient alignment.
The link NevemTeve posted gives a good overview of address space randomization.

All the addresses you are looking at are virtual addresses, not physical addresses. Every access to memory is translated by the hardware from a virtual address to a physical address. Each process has its own set of translation tables for converting virtual address to physical address. So the same virtual address in two different processes is normally not the same physical address. The stack and heap are private to each process, so in that case, same virtual address is absolutely not the same physical address.

Trying to understand the aspects of memory allocation that you are looking at is a giant distraction to finding your problem.

What you should understand about memory allocation is that the chunks are typically close together and have no physical "walls" between them. In the case of memory allocated by new, there are 8 bytes of important control data between each chunk of allocated memory. If you corrupt any of those, the memory allocator can get badly confused.

The most common way a bug similar to your description occurs is allocating an array but using it as a larger array, overwriting control information following the allocation. Do you allocate any arrays? Try to check the indexing to make sure the index does not exceed size minus one of the allocation.

The second most common is "stale pointer", allocate an object, deallocate the object, then keep writing to it, corrupting the free memory pool.

I want to make sure the OP understands that setting all invalid pointers to zero is an important diagnostic aid, not a direct requirement. If a pointer is invalid and unused, no harm is done. Setting pointers to zero whenever they are not valid won't fix the bug. It may make a bug easy to find that would otherwise be nearly impossible to find.

Using a stale pointer almost never has any immediate symptom. The symptom is typically delayed and distant, so the symptom gives no hint about the bug. So the bug is very hard to find. Often the bug is the worst kind for a professional programmer: No recognized symptom at all, just an unnoticed wrong answer.

But if every pointer that is not currently valid is set to zero, then using an invalid pointer gives an immediate consistent failure at the point of the bug. The failure directly indicates the bug, so the bug is easy to diagnose and correct.

1 members found this post helpful.

Hi johnsfine and sundialsvcs..
Thanks for your thoughts.. looks like i have to explore more based on your inputs.. Below I have pasted the code snippet of which im facing the issue..These lines of code are executed when the system is booted,so i belived sufficient memory shall be available to the system..

Here the for loop should run for 431 times but the process gets hanged inside the try block forever after memalloc for 405th(not always 405th time) iteration..
Below are the output of my debug printf statement added for your reference..
Here the printf and system(free -b) are debug lines added by me to find the exact line of code at which hangs occurs..These are not as part of the final code in which the hang issue was observed..

Sample output:

Memallocated for 404 .Size = 16 . 16.
total used free shared buffers cached
Mem: 64356352 63012864 1343488 0 1589248 43859968
-/+ buffers/cache: 17563648 46792704
Swap: 0 0 0

Memallocated for 405 .Size = 16 . 16.
total used free shared buffers cached
Mem: 64356352 63029248 1327104 0 1589248 43868160
-/+ buffers/cache: 17571840 46784512
Swap: 0 0 0

This process is a User interface process designed with Qt3.0 version and kernal version is 2.4.18..Pls share your ideas and areas of suspect as i can concentrate more on that.. as of now my suspect is on new operator getting blocked..

1) Why do you keep thinking this is a memory allocation problem, when you have no evidence of that?

2) Where do the file names come from (contents of BmpFileNameTable)? Is there extra code you haven't shown? Or is it as you have shown with null file names, so QPixmap should fail every time?

I have no idea what the QPixmap constructor does when you give it a directory instead of a file. I'm surprised it does something worse on the 406'th time you do that. If it were logging errors to a pipe that no process is reading, I would expect exactly the hang you see. But I would be a bit surprised to learn it is logging errors to a pipe.

BTW, sizeof() is a compile time operation. It is not telling you anything about what was allocated at run time.

In case you might be correct about a memory allocation problem, I would expect the cause to be ulimit or something similar. Try the command
see if anything looks strange.

Also, it would help to know what files are open in the hung process while it is hung. Once it is hung, either use another terminal, or use ^Z to make the current terminal usable for more commands. Find out the pid of the hung process (with ps or similar tool) then use
replacing pid with the pd of the hung process.

How many and what files does it have open? Did it hit the ulimit on open files?