gdb shows wrong addresses while zeroing a buffer

My objective is to initialize a buffer in assembly. I use NASM on a 64bit-linux and gdb for debugging. The relevant assembler is the following (I copy-pasted from gdb's TUI mode, so you can see the line numbers):

│   4           section .data 
│   5            
│   6           length dd 4096       
│   7           format db "%20ld",10,0         
│   8         
│   9           section .bss 
│   10
│   11          buffer resd 4096

│   83          init_buffer: 
│   84            ;we will use r8 for our counter 
│   85            ;and r9 for the buffer base address 
│   86            xor r8,r8
│   87            lea r9, [buffer]
│   88            mov r10d, DWORD 0xDADADA; not 0 to make debugging easier
│   89            mov eax, [length]   
│   90            movsxd rax, eax
│   91          .init_buffer_loop:
│   92            mov [r9 + r8*4], r10d
│   93            inc r8 
│   94            cmp r8, rax 
│   95            jb .init_buffer_loop
│   96            ret

I use the following command to build the program (I use printf at another moment):

nasm -F dwarf -f elf64 myProgram.asm && gcc -g myProgram.o

While debugging another problem (I use gdb -tui a.out), I realised that the value in r9 and the address of buffer are different:

(gdb) b    87
Breakpoint 1 at 0x4011a8: file myProgram.asm, line 87.
(gdb) r
Starting program: /path/to/my/program

Breakpoint 1, init_buffer () at myProgram.asm:87
(gdb) p    &buffer
$1 = (char **) 0x7ffff7fa0250 <buffer>
(gdb) n
(gdb) i    r r9
r9             0x405034            4214836
(gdb) n
init_buffer.init_buffer_loop () at myProgram.asm:92
;//some next instructions are missing here, we are at line 94 now:
(gdb) x    /1xd 4214836
0x405034 <buffer>:    14342874
(gdb) x    /4x 4214836
0x405034 <buffer>:    0x00dadada    0x00000000    0x00000000    0x00000000
(gdb) p    (int[4])buffer
$3 = {0, 0, 0, 0}

Is there a mistake in the assembly code? Or am I debugging it wrong? I asked some programmers, who could not explain it to me, but they hadn't much experience with gdb-ing assembly...

As the comments indicated, there is another variable called buffer in another source file of glibc. Changing the variable name to puffer gives the expected results. Furthermore, the following line should have made me skeptical:

$1 = (char **) 0x7ffff7fa0250 <buffer>

gdb did not interfered types in my assembler code, but it knew that I put char **s in my buffer.