note bulk88 <code> my $a = "a"; my $b = "b"; my $offset = \$b - \$a; printf "a: %s\nAddress: %p\n", $a, $a; printf "b: %s\nAddress: %p\n", $b, $b; printf "Buffer Offset: %d\n", $offset; </code> 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 *). <br><br> <i> 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. </i> <br><br> 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. <br><br> Can I cause a buffer overflow on the C stack to |-|4(|<()&#1071; a Perl machine with a [href://] or [href://] or put shellcode on the C stack and then execute it? <br><br> The answer is no. If XS is involved, thats a different story. <br><br> 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 [href://|illguts] for more. <code> ntdll.dll!_KiFastSystemCallRet@0() ntdll.dll!_ZwWaitForMultipleObjects@20() + 0xc kernel32.dll!_WaitForMultipleObjectsEx@20() - 0x48 user32.dll!_RealMsgWaitForMultipleObjectsEx@20() + 0xd9 user32.dll!_MsgWaitForMultipleObjects@20() + 0x1f > perl512.dll!win32_msgwait(interpreter * my_perl=0x003942ac, unsigned long count=1, void * * handles=0x0006f998, unsigned long timeout=4294967295, unsigned long * resultp=0x00000000) Line 2181 + 0x19 C perl512.dll!win32_spawnvp(int mode=0, const char * cmdname=0x008230bc, const char * const * argv=0x00822fe4) Line 4249 + 0x19 C perl512.dll!do_spawn2(interpreter * my_perl=0x003942ac, const char * cmd=0x00822e9c, int exectype=2) Line 784 + 0x11 C perl512.dll!Perl_do_spawn(interpreter * my_perl=0x003942ac, char * cmd=0x00822e9c) Line 820 + 0xf C perl512.dll!Perl_pp_system(interpreter * my_perl=0x003942ac) Line 4277 + 0x5e C perl512.dll!Perl_runops_debug(interpreter * my_perl=0x003942ac) Line 2049 + 0xd C perl512.dll!S_run_body(interpreter * my_perl=0x003942ac, long oldscope=1) Line 2308 + 0xd C perl512.dll!perl_run(interpreter * my_perl=0x003942ac) Line 2233 + 0xd C perl512.dll!RunPerl(int argc=3, char * * argv=0x00282478, char * * env=0x00285260) Line 270 + 0x9 C++ perl.exe!main(int argc=3, char * * argv=0x00282478, char * * env=0x00282de8) Line 23 + 0x12 C perl.exe!mainCRTStartup() Line 398 + 0xe C kernel32.dll!_BaseProcessStart@4() + 0x23 </code> 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. <br><br> If you want to see Perl bytecodes decoded, read my post [id://981970]. If you want to know how SVs allocate their buffers, see [apc://sv.c#l1461]. If you want to know how malloc works, see [href://] or for an actual implementation, this is HeapAlloc from windows, [href://]. 984280 984495