5

I'm debugging php. When looking at a place in memory where I know a pointer to an address is, I see the pointer - for example 22810408 (0x08048122) - this is when using the CLI version of php.

HOWEVER, when I'm using apache2 and attempting to do the same thing, I don't see a pointer to the real address. Instead, I see an offset from the ELF header that when added to the address of the ELF header, gives me the "real" address. For example, if the "real" address was 0x08048122, and the ELF header was at 0x08048000 then I would see 22010000 (0x122) at this same position.

The problem arises when I try to figure out the "real" address of something that is on the stack. The "real" address is supposed to be 0xbfccxxxx, but when adding the number I find to the ELF header, things just don't add up! I get all the wrong addresses.

I've already tried googling for a long time, but I am really not sure how to word this correctly, or what to search for.

So, what I'm essentially looking for is more information on WHY Apache has an offset instead of a real memory address, and how this all relates to addresses on the stack. Could anyone give me any pointers to material that might clarify?

mario
  • 144,265
  • 20
  • 237
  • 291
optional
  • 51
  • 1
  • Could you be looking at offsets in an executable file, which isn't loaded yet, rather than at addresses in a running process? – ugoren Jan 14 '12 at 19:50
  • That's probably how it works. Do you have any more information on how this works? – optional Jan 14 '12 at 19:59
  • 1
    Your "pointer" got me some better results googling. It seems that to apache, php is a .so, not a real executable file. So, what I see is offsets, not real addresses, and this is the cause. What I still don't understand completely is how to go from my "offset" to the real virtual memory address. I'm still reading, but any clarification or obligatory reading would be much appreciated. At least now I understand that I cannot simply add my ELF address to get the right one - it seems I need to parse the relocation table.. – optional Jan 14 '12 at 20:47
  • 1
    How exactly are you looking at the pointers? GDB? What commands? – ugoren Jan 15 '12 at 07:46
  • 1
    Have you considered the fact that address space layout randomization is in effect on most modern operating systems. This means that shared libraries get loaded at random locations for each process.. maybe this has something to do with your calculations not being right. – Garuda Jan 18 '12 at 18:37

1 Answers1

2

Apache utilizes mod_php, a dynamically linked shared object library (.so). See what is mod_php?. Where as PHP-CLI is a front-end to the zend API (php executable).

mod_php on its' side loads and utilizes the zend API to parse and return PHP files to apache. As you can see there's a lot of indirection here. This method works better and faster than letting apache use PHP as a daemon or similar.

When debugging PHP you normally work on a much higher level than this, because even if you get the offsets right; PHP datatypes are not 1:1 those of C (because of PHP's duck typing) and for associative arrays and objects the representation in memory is very different than that of a C object.

I would recommend you to use a specialized PHP debugger to debug PHP applications.

Community
  • 1
  • 1
thwd
  • 23,956
  • 8
  • 74
  • 108