MIPS printing strange empty square - mips

Question

I am writing a code to read a NxN array using macros in MIPS, it has no problems reading, but when the function printString is called after a few uses, it starts printing a strange square. I found that commenting the line sw $v0, ($t9) in readArray will make the function print as expected, however the contents that were read won't be saved anymore (and the function will be useless).
My code is the following:
.data
.macro printString(%string)
.data
string: .asciiz %string
.text
li $a0, 0
li $v0, 0
la $a0, string
li $v0, 4
syscall
.end_macro
.macro printInt(%int)
.text
li $a0, 0
li $v0, 0
add $a0, $zero, %int
li $v0, 1
syscall
.end_macro
.macro alloc(%size)
.text
li $a0, 0
li $v0, 0
add $a0, $zero, %size
li $v0, 9
syscall
.end_macro
.macro end()
.text
li $v0, 10
syscall
.end_macro
.macro readInt()
.text
li $v0, 5
syscall
.end_macro
.macro readArray(%array, %size)
.data
array: %array
.text
rAMain:
la $t4, array
add $t5, $zero, %size
li $t6, 0
li $t7, 0
rALoop:
arrayIndex($t4, $t5, $t6, $t7)
move $t9, $v0
printString("Write a value:[")
printInt($t6)
printString("][")
printInt($t7)
printString("]: ")
readInt()
sw $v0, ($t9)
addi $t7, $t7, 1
blt $t7, $t5, rALoop
li $t7, 0
addi $t6, $t6, 1
blt $t6, $t5, rALoop
.end_macro
.macro arrayIndex(%array, %columnNumber, %i, %j)
.data
array: %array
.text
la $t0, array
add $t1, $zero, %i
add $t2, $zero, %j
add $t3, $zero, %columnNumber
mul $v0, $t1, $t3
add $v0, $v0, $t2
sll $v0, $v0, 2
add $v0, $t0, $v0
.end_macro
.text
main:
jal readN
alloc($s1)
move $s0, $v0
readArray($s0, $s1)
end()
readN: ######
printString("Write the value of N: ")
readInt()
move $s1, $v0
jr $ra
Picture of the error:

Answer 1

Usage of:
.data
array: %array
in your readArray macro does not allocate any storage when the corresponding parameter is a register — in fact, array: $t0 doesn't make any sense to me, but somehow MARS allocated zero bytes of storage after the array label without complaining of syntax error.
The data declarations .data ... array: are global declarations, which are performed at compile/assemble time, rather than dynamic allocations performed at runtime.  This is one reason I'm surprised that MARS accepts a register name as an argument here, but none-the-less, it surely isn't doing what you want.