|more useful options|
Why does it matter what the offset is between 2 SV *? SV *s are allocated from a pool/arena/bucket system. I dont think the delta between 2 SV *s means anything at all and I believe they are random (someone correct me if my knowledge of the SV arena allocator is wrong) (for example, someone could think that a SV * with a higher pointer is "newer" or later in the perl script than an lower SV *).
Thanks for this response! It pretty much is a reflection of my understanding of Perl's memory addressing capabilities so far. As for my underlying objective, I am trying to understand the concept of buffer overflow and have been experimenting around with it a little. In particular, I have been unable to create a simple buffer overflow (in analogy to how this would be achieved in a simple C programme) and am therefore trying to gain deeper insight into how Perl manages memory allocation. It's exactly at this point that I would like to see what values certain memory addresses have been allocated.
Maybe I am being harsh, since you seem to very little understanding of C, yet you are very interested in "memory allocation" and as you said "buffer overflows" (which nearly impossible in the Perl interp, XS excluded). I will post this question and answer it.
Can I cause a buffer overflow on the C stack to |-|4(|<()Я a Perl machine with a http://en.wikipedia.org/wiki/Return-to-libc_attack or http://en.wikipedia.org/wiki/Return-oriented_programming or put shellcode on the C stack and then execute it?
The answer is no. If XS is involved, thats a different story.
The actual contents of Perl language variables (like strings/PVs) never appear on the C stack. Perl interp does not use fixed length buffers or vulnerable printfs or strlens. Perl interp length tracks all buffers at all times, (XS excluded). Everything your see in the Perl Language is malloced from the heap, not from the C stack. The Perl language callstack and the C callstack are not related. Perl code is not compiled into C, it is compiler into Perl bytecode. Unless you are using XS, with callbacks into the perl interp with call_*(). 99% of the runtime of the Perl interp is spent in Perl_runops-* and 1 pp_* function deep after runops, from a C stack viewpoint that is. A pp_* (XS excluded) will almost never cause a second runops to appear on the C stack (except tied/magic). The Perl callstack is not maintained on the C stack, its a separate bunch of non contiguous malloced stacks, see illguts for more.
The callstack snapshot was taken while the perl interp was frozen. The command was "perl -e "system('pause');". The above example is Windows only of course.
If you want to see Perl bytecodes decoded, read my post Re: [B::Deparse] Trying to find sub's code. If you want to know how SVs allocate their buffers, see sv.c#l1461 in perl.git. If you want to know how malloc works, see http://en.wikipedia.org/wiki/Dynamic_memory_allocation#Dynamic_memory_allocation or for an actual implementation, this is HeapAlloc from windows, http://doxygen.reactos.org/d8/d68/lib_2rtl_2heap_8c_source.html#l02011.