memory allocation during {.global.} init breaks GC

[arnetheduck]

[arnetheduck@tempus tmp]$ more testit.nim
proc init(): string =
  for a in 0..<10000000:
    result.add 'c'

proc f() =
  var a {.global.} = init()
  var b {.global.} = init()
  var c {.global.} = init()

  echo a.len
  echo b.len
  echo c.len

f()
[arnetheduck@tempus tmp]$ nim c --hints:off -r testit.nim 
9920232
9920232
10000000
[arnetheduck@tempus tmp]$ nim --version
Nim Compiler Version 1.4.2 [Linux: amd64]
Compiled at 2020-11-30
Copyright (c) 2006-2020 by Andreas Rumpf

git hash: 3fb5157ab1b666a5a5c34efde0f357a82d433d04
active boot switches: -d:release

this is because globals are registered to the global variable table after init is run, meaning that any memory allocated while initializing globals will be collected by the gc

[arnetheduck]

v1.2.6 also affected

[timotheecour]

this bug was closed but https://dev.azure.com/nim-lang/255dfe86-e590-40bb-a8a2-3c0295ebdeb1/_apis/build/builds/13586/logs/89 logs shows:

hostOS: linux, hostCPU: i386, int: 4, float: 8, cpuEndian: littleEndian, cwd: /home/vsts/work/1/s
...
2021-02-25T13:48:39.2508482Z �[32mPASS: �[36mtests/gc/trace_globals c  -d:release --gc:markAndSweep      �[34m ( 2.22 sec)�[0m
2021-02-25T13:48:39.2509276Z �[1m�[31mFAIL: �[36mtests/gc/trace_globals c  --gc:boehm�[0m
2021-02-25T13:48:39.2510185Z �[1m�[36mTest "tests/gc/trace_globals" in category "gc"�[0m
2021-02-25T13:48:39.2510880Z �[1m�[31mFailure: reOutputsDiffer�[0m
2021-02-25T13:48:39.2511671Z �[33mExpected:�[0m
2021-02-25T13:48:39.2512205Z �[1m10000000
2021-02-25T13:48:39.2512640Z 10000000
2021-02-25T13:48:39.2512961Z 10000000
2021-02-25T13:48:39.2513436Z �[0m
2021-02-25T13:48:39.2513947Z �[33mGotten:�[0m
2021-02-25T13:48:39.2514669Z �[1mGC Warning: Repeated allocation of very large block (appr. size 9920512):
2021-02-25T13:48:40.1763012Z 	May lead to memory leak and poor performance.
2021-02-25T13:48:40.1764453Z 10000000
2021-02-25T13:48:40.1765312Z 10000000
2021-02-25T13:48:40.1766131Z 10000000
2021-02-25T13:48:40.1766665Z 
2021-02-25T13:48:40.1768272Z �[0m
2021-02-25T13:48:40.1769928Z �[32mPASS: �[36mtests/gc/trace_globals c  -d:release --gc:boehm             �[34m ( 0.95 sec)�[0m
2021-02-25T13:48:40.1771306Z FAILURE! total: 126 passed: 119 skipped: 6 failed: 1
2021-02-25T13:48:40.1811421Z progress[all]: 79/126 starting: cat: pragmas

[Araq]

This is a Boehm GC specific problem and not a bug. We can disable the test for --gc:boehm.

[timotheecour]

I can't reproduce the original bug report (tried 1.2.6 and 1.4.2, on both osx and linux via docker
Linux f27b084ca41f 4.19.121-linuxkit #1 SMP Tue Dec 1 17:50:32 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

@arnetheduck what system were you using?

[arnetheduck]

linux/fedora - add a 0 to the loop count - this relies on the gc triggering at the right moment - it's not arch specific, it's a bug that's fairly easy to see in the logic of the init order, pre-fix

[arnetheduck]

https://play.nim-lang.org/#ix=2TVG