Memory leak with arc gc

[Frogmellon]

The occupied memory logged out for the following sample grows apparently indefinitely.

Example

import os

var testSeq:seq[int]

proc Update(): void =
    # testSeq.add(0) # uncommenting this line fixes the leak
    testSeq = @[]
    testSeq.add(0)
    echo GC_getStatistics()
    echo "testSeq length:", testSeq.len()

while true:
    Update()
    sleep(100)

Current Output

[GC] total memory: 528384
[GC] occupied memory: 80

testSeq length:1
[GC] total memory: 528384
[GC] occupied memory: 96

testSeq length:1
[GC] total memory: 528384
[GC] occupied memory: 112

testSeq length:1
[GC] total memory: 528384
[GC] occupied memory: 128

testSeq length:1
[GC] total memory: 528384
[GC] occupied memory: 144

Additional Information

As noted in the code sample using the seq before clearing it keeps the occupied memory constant as expected.

Compiled with
nim c --gc:arc memtest.nim

$ nim -v
Nim Compiler Version 1.3.3 [MacOSX: amd64]

[ghost]

I'm not sure if GC_getStatistics is supposed to work with --gc:arc 🤔

[ghost]

import os

var testSeq: seq[int]

proc Update() =
  testSeq = @[]
  testSeq.add(0)

proc main = 
  while true:
    Update()
    sleep(1)

main()

Ah nvm, seems like a real leak, with valgrind (--gc:arc -d:useMalloc -d:danger --debugger:native) and a main proc added:

==30794== HEAP SUMMARY:
==30794==     in use at exit: 58,672 bytes in 3,667 blocks
==30794==   total heap usage: 3,667 allocs, 0 frees, 58,672 bytes allocated
==30794== 
==30794== 58,656 bytes in 3,666 blocks are definitely lost in loss record 2 of 2
==30794==    at 0x483BB65: calloc (vg_replace_malloc.c:760)
==30794==    by 0x1097B0: alloc0Impl__KzdpcuLT9aef9bsiSHlIu9aFg_2 (malloc.nim:8)
==30794==    by 0x1097B0: allocShared0Impl__KzdpcuLT9aef9bsiSHlIu9aFg (malloc.nim:28)
==30794==    by 0x1097B0: newSeqPayload (seqs_v2.nim:37)
==30794==    by 0x1097B0: prepareSeqAdd__CtW9b5ZpLjmwThCpYoOJPkQ (seqs_v2.nim:53)
==30794==    by 0x1098B6: add__MIAbjRZGBQlNfywJeCn8AQ (seqs_v2.nim:104)
==30794==    by 0x10B11C: Update__GoSFmsmy4BRZ19b53GTO5rw_2 (Projects/sklad/leak.nim:7)
==30794==    by 0x10B11C: main__GoSFmsmy4BRZ19b53GTO5rw (Projects/sklad/leak.nim:11)
==30794==    by 0x10B11C: NimMainModule (Projects/sklad/leak.nim:14)
==30794==    by 0x10B11C: NimMainInner (system.nim:2130)
==30794==    by 0x10B21B: NimMain (system.nim:2138)
==30794==    by 0x10B21B: main (system.nim:2145)
==30794== 
==30794== LEAK SUMMARY:
==30794==    definitely lost: 58,656 bytes in 3,666 blocks
==30794==    indirectly lost: 0 bytes in 0 blocks
==30794==      possibly lost: 0 bytes in 0 blocks
==30794==    still reachable: 16 bytes in 1 blocks
==30794==         suppressed: 0 bytes in 0 blocks

[ghost]

Workaround - use testSeq.setLen(0) instead of testSeq = @[]

[Araq]

I think the "isFirstWrite" analysis is wrong for global variables, ping @Clyybber