8
char *ptr = (char*) malloc(40);
printf("%u",ptr);

56737856 (some output)

Now, if i am not incorrect the output that we see above is not a physical address but from the virtual address space. Am i correct?

Is there any way to see the actual physical address? Or vice versa (if my above assumption is wrong), and does all the internal implementation of malloc necessarily use the jemalloc algorithm?

RajSanpui
  • 11,556
  • 32
  • 79
  • 146
  • 3
    `printf("%p", (void *)ptr);` – David Ranieri Jun 08 '13 at 17:05
  • Hmm. `/proc/self/maps` says where the heap is in terms of virtual addresses, but not physical addresses. – aschepler Jun 08 '13 at 17:10
  • @aschepler: Do you mean the address above is from the virtual address range, that we normally see when printing? – RajSanpui Jun 08 '13 at 17:12
  • @DavidRF: So `%p` is for the addresses that the pointers actually holds, so you mean using `%p` we can actually print the physical addresses? – RajSanpui Jun 08 '13 at 17:14
  • 1
    The address is a virtual address. You will never see physical addresses - and indeed the physical address *can* change. – Nik Bougalis Jun 08 '13 at 17:15
  • @kingsmasher1, he's saying that `%p` and *not* `%u` is the correct format specifier for printing a pointer. – Carl Norum Jun 08 '13 at 17:18
  • Can someone help me answer about the `jemalloc` part? – RajSanpui Jun 08 '13 at 17:27
  • If I am not mistaken (or outdated): I think that glibc (standard C library on many common Linux distros) actually uses a dlmalloc variant (malloc based on Doug Lea's implementation). So I am not sure why you think that jemalloc is used ? – Ingo Blackman Jun 09 '13 at 03:02

3 Answers3

11

All addresses you see in user space applications are virtual addresses.

Physical addresses are only of concern to the kernel. The mapping from virtual to physical addresses is complex, given that:

  • Not all virtual addresses have physical addresses at all. (For instance, pages that are unmapped, lazily zero-filled, or swapped out have no physical address.)
  • Physical addresses may change without warning (e.g, if a page is swapped out and back in, or if a shared page is copied).

Outside of some very unusual situations (mostly having to do with messing around with hardware), you should not care about physical addresses.

  • So as DavidRF pointed out above, if i understood what he is trying to say, can we print the physical address using the `%p` format specifier? – RajSanpui Jun 08 '13 at 17:17
  • No. `%p` is not magic. It just prints out the address you pass it, and that address will be a virtual address. –  Jun 08 '13 at 17:18
  • @kingsmasher1, nops, I was just correcting the format, using `%p` you are still accessing to the virtual address mapped by the OS – David Ranieri Jun 08 '13 at 17:25
3

Yes, on a platform with virtual memory it is an address in process address space, i.e. it is an address in virtual memory. In such systems, at the typical application level the actual physical address in RAM makes no meaningful sense whatsoever - even if it is already known at that moment, it can change at any moment anyway. The physical RAM address is beyond your control. So, at the typical application level when people speak about "physical addresses", they normally refer to what you printed - the address in the process address space, i.e. the virtual address.

Just don't use %u to printf pointers. Use %p. Or at least convert your pointer to an appropriately sized unsigned integer type and use format specifier for that type.

AnT stands with Russia
  • 312,472
  • 42
  • 525
  • 765
2

Is there any way to see the actual physical address?

On an x86 architecture in real mode, there's no memory protection and you get back the actual physical address, so you can do things like overwriting the 0x0 address.

Here's a code snippet from 'Memory Management: Algorithms and Implementations in C/C++' that can crash a DOS running computer:

void main()
{
    unsigned char* ptr;
    int i;
    ptr = (unsigned char *)0x0;
    for(i = 0; i < 1024; i++)
    {
        ptr[i]=0x0;
    }
    return;
}

If I may quote Wikipedia:

Real mode provides no support for memory protection, multitasking, or code privilege levels. Before the release of the 80286, which introduced Protected mode, real mode was the only available mode for x86 CPUs. In the interests of backwards compatibility, all x86 CPUs start in real mode when reset.

Nobilis
  • 7,310
  • 1
  • 33
  • 67
  • While this is interesting, it doesn't answer the question at all. –  Jun 08 '13 at 17:15
  • It answers the question on whether there is a way to get the physical address. I'll add a note if that will improve the answer. – Nobilis Jun 08 '13 at 17:17
  • 1
    It has nothing to do with Linux. Linux does not run in real mode. –  Jun 08 '13 at 17:17
  • 1
    I disagree; it answers it in one specific situation. – Ernest Friedman-Hill Jun 08 '13 at 17:18
  • 1
    It answers part of the question, because the answer is "it depends". if the system is a normal desktop linux, chances, are that malloc returns a vritual page. If the systm is some embedded system it may not have virtual adresses at all. Malloc is what is needed for a particular environment. – Devolus Jun 08 '13 at 17:18
  • Well, apparently there is a kludge on running Linux in real mode: http://stackoverflow.com/questions/855150/is-it-possible-to-shutdown-linux-kernel-and-resume-in-real-mode – Nobilis Jun 08 '13 at 17:19
  • @Nobilis: That would be a way to *possibly* run a real-mode application from Linux, not a way to run Linux in real mode (which is impossible). In any case, it's almost certainly not what the OP is asking about. –  Jun 08 '13 at 17:21
  • Fair enough, to my knowledge the GRUB loads part of the kernel in real mode, so yes it won't be the entire kernel and therefore Linux. – Nobilis Jun 08 '13 at 17:25
  • @Nobilis: This is starting to go off track, but: the Linux kernel is loaded in real mode because that's the state the bootloader leaves the CPU in. Switching to protected (or long) mode is one of the first things the kernel does at startup - the system is never **running** in real mode. –  Jun 08 '13 at 17:59