Global var defined within a proc gets initialized more than once under ORC

[nitely]

Description

While experimenting with globals and threads I found they get reassigned each time the proc where they are defined is called. This seems to cause race conditions in threads, even though the global var is not mutated. The example is a reduced version that just shows bar is called more than once. If this is intended, the docs need fixing. Works as expected under refc.

proc bar(n: int): seq[int] =
  echo "bar"
  result = newSeq[int](n)
  for i in 0 .. result.len-1:
    result[i] = i

proc genfoo(): seq[int] =
  var foo {.global.} = bar(100)
  return foo

proc fooworker() =
  var f = genfoo()
  doAssert f.len == 100, $f.len

proc main() =
  fooworker()
  fooworker()

main()

Nim Version

Nim Compiler Version 2.3.1 [Linux: amd64]
Compiled at 2025-01-17
Copyright (c) 2006-2025 by Andreas Rumpf

git hash: 70d057f
active boot switches: -d:release

Current Output

bar
bar

Expected Output

bar

Known Workarounds

No response

Additional Information

No response

[nitely]

mmh looks like a dup of #17552 ; the workaround does not work in this case, though.

[metagn]

A workaround is to mark genfoo as {.nodestroy.}

[nitely]

I get an OOM error when adding nodestroy in my real program. But adding things that should do nothing like doAssert true later result in a sigsevg, or a index error...

When checking the above example (with nodestroy) in valgrind it looks like there are some double free total heap usage: 2 allocs, 3 frees. So likely some memory corruption.

[Araq]

A workaround is to mark genfoo as {.nodestroy.}

No, it's not. ;-)

[nitely]

proc genfoo(): lent seq[int] {.nodestroy.} = i.e: adding lent + nodestroy seems to work. The global is never destroyed though. but this should not be allowed pretty sure -> #24624