Address of local variable not within the address range of stack shown by smaps

Question

I got the stack memory info of a process:

cat /proc/17647/smaps |grep stack

7ffff8840000-7ffff8853000 rwxp 7ffffffe9000 00:00 0                      [stack]

I only know 7ffff8840000-7ffff8853000 is the beginning and end boundary of the stack segment in the VM address, and the 4th column '7ffffffe9000' is the beginning RAM address of the VM address shown in the 1st column; the mapping relation is defined by the pagetable.

Here, I have 1 question: does the first byte in this VM segment has the RAM address 7ffffffe9000 ? In this case, should I get a variable's VM address (for example, x ) to RAM address with this expression: (x - 7ffff8840000)+ 7ffffffe9000

I ran gdb on this process to see address of some local variable (which only can be within the stack),

gdb -p 17647
.....
b xx.cpp:100
....
p &var1
$2 = (int *) 0x4eb02a40

Here, I have a question: var1 is a local variable in a function (which can not be wrong), but its address 0x4eb02a40 is neither in between VM address 7ffff8840000 - 7ffff8853000 , nor is it nearby RAM address 7ffffffe9000 as 0x4eb02a40 is so much less than 7ffffffe9000 , so, is 0x4eb02a40 a VM address or a RAM address? How to get the real RAM address of my variable?

Another question: by using both gdb and pmap or cat /proc/17647/smaps, how to judge that a variable address is in heap or stack or data segment?

Answer 1

var1 is a local variable in a function (which can not be wrong), but its address 0x4eb02a40 is neither in between VM address 7ffff8840000-7ffff8853000

Two possible explanations. Most likely one:

• Your program is multi-threaded, and you hit the breakpoint in thread other than main.

Each thread has its own stack region, which libpthread.so obtains from mmap . Such mappings do not have stack in /proc/self/maps -- as far as the kernel is concerned, this is just a regular anonymous mapping and there is nothing special about it.

Less likely one:

• Your program uses coroutine-style programming (perhaps with makecontext , perhaps with longjmp ), and your breakpoint is in a coroutine that executes on a separate stack.