Re: Strange backtrace

John Tapsell wrote:
>2009/7/30 John Tapsell <johnflux@xxxxxxxxx>:
>>> However, there's just no way that the pointer can change from
>>> 0x82097e8 to 0xbfb99b78. The former pointer is an address in the
>>> heap, while the latter is on the stack.
>>
>> 1) How can you tell?
>
>Oooo, I was having trouble because of the way that they are written.
>The first number only has 7 digits.  So it's actually:
>
>0x082097e8
>0xbfb99b78
>
>Now it's much more obvious that "0x08" is right at the top (heap) and
>"0xbf" is near the bottom (stack).  Thanks to Raphael for private
>messaging me this answer :-)
>
>Although, 0xbf  seems to be roughly 1GB from the end ( 1.00429643
>gigabytes according to google).  This seems like a very large stack.
>Is this reasonable?

Yes. On x86 Linux, the stack area is very close to the 3 GB border and 
grows down. Looking at konsole's /proc/pid/smaps right now, it says:

bfccd000-bfce1000 rwxp 00000000 00:00 0          [stack]     
Size:                 80 kB

The memory distribution on x86 has had very few changes in the addressing 
area. The original was:

        0x08048000      program start
                                .text
                                .rodata
                                .data
                                .bss
                                heap
        0x40000000      start of library loads
        0x80000000      end of library loads
                                stack bottom
        0xbffffffe      stack top
        0xc0000000      start of kernel area
        0xffffffff      end of kernel area

As you can see, that model would limit the heap growth to the 1 GB 
barrier, where libraries area loaded. So some glibc version a couple of 
years ago changed that, and libraries started being loaded just under the 
stack area (at 0xb8000000) and using addresses down.

That means the heap now can grow all the way towards the bottom of the 
last library loaded, which means it's roughly 2.7 GB.

For example, my konsole's last mmapped area is at 0xafcc5000, whereas the 
heap starts at 0x0814a000. That's a theoretical maximum heap of 2683 MB. 
(Though not entirely true because large allocations are mmapped directly)

If you have more than one thread, each secondary thread's stack is an 8 MB 
mmapped area (you can easily tell them from anything else because they 
have permissions rwxp with very small RSS).

The only other change I know of this addressing area was in early Linux 
kernels that supported more than 1 GB. They did so by moving the kernel 
area split to the 2 GB mark. But those kernels are rare today: the 3:1 
split is much more common.

PS: the value 0x08048000 is arbitrary. It's written by the linker to the 
ELF executables. Use readelf -l /bin/ls to see an example.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

signature.asc
Description: This is a digitally signed message part.

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<