Does LLDB change the address of environment variables for C programs?

In particular, why / how? I was messing around with buffer overflows on my Mac and I wrote a genv program to dump the memory address of environment variables. I got 3 different addresses (obviously they will change on every run - that's not what's going on here)

SHELLCODE ADDR 1) I run the program from the command line

ben:~/scripts$ genv SHELLCODE
SHELLCODE                           &0x7fff5c455d3d

      

        
        
        
      

    

SHELLCODE ADDR 2) I run the program through LLDB and check registers after setting some breakpoints

ben:~/scripts$ lldb genv SHELLCODE
### intermediary steps
(lldb) x/2s $rsp+0x137
0x7fff5fbffd3f: "PROGRAM=Apple_Terminal"
0x7fff5fbffd56: "SHELLCODE=helloworld"

      

        
        
        
      

    

SHELLCODE ADDR 3) I continue from the breakpoint and dump genv output to stdout

(lldb) c
Process 2748 resuming
SHELLCODE                           &0x7fff5fbffd60
Process 2748 exited with status = 0 (0x00000000) 

      

        
        
        
      

    

So 2) and 3) SHELLCODE addresses differ by 10

ben:~$ python -c 'print hex(0x7fff5fbffd60 - 0x7fff5fbffd56)'
0xa

      

        
        
        
      

    

but 2) and 1) differ much more

ben:~$ python -c 'print hex(0x7fff5fbffd60 - 0x7fff5c455d3d)'
0x37aa023

      

        
        
        
      

    

Below is my genv program

// genv.c
// print address in memory of environment vars
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[])
{
   int i;
   if (argc == 1)
   {
     printf("Improper Usage: No env args\n");
     exit(-1);
   }
   for (i = 1; i < argc; i++)
   printf("%-36s%p\n", argv[i], getenv(argv[i])); // Format into columns w/ "%-36s"
   return 0;
}

      

        
        
        
      

    

Obviously the genv stack is being built somewhere else when it is run in LLDB, and I guess that makes sense (does it complicate buffer overflows and other memory hackers or something else entirely?). HOWEVER - why is there such an offset of 10 between register checking and actually printing to stdout in the same run?