SIGSEGV with object variants and RTTI about nim

[alex65536]

!nim c

[alex65536]

!nim c

import std/sequtils

type
  SomeObj* = object of RootObj

  Item* = object
    case kind*: 0..1
    of 0:
      a*: int
      b*: SomeObj
    of 1:
      c*: string

  ItemExt* = object
    a*: Item
    b*: string

proc do1(x: int): seq[(string, Item)] =
  result = @[("zero", Item(kind: 1, c: "first"))]

proc do2(x: int, e: ItemExt): seq[(string, ItemExt)] =
  do1(x).map(proc(v: (string, Item)): auto = (v[0], ItemExt(a: v[1], b: e.b)))

echo do2(0, ItemExt(a: Item(kind: 1, c: "second"), b: "third"))

[ringabout]

@alex65536 wow, your insights are really helpful. I think it's mostly likely that copy needs to zero memery the union before assignement. I'm working on it. Thank you very much!

[beef331]

how destructors of old values behave when they encounter zeroed memory

Destructors are supposed to be written in such a way that 0'd memory indicates "this was moved"

[github-actions]

🐧 Linux bisect by @alex65536 (contributor)

devel 👎 FAIL

Output

IR

Compiled filesize 0 bytes (0 bytes)

Stats

• Started 2024-06-07T03:45:24
• Finished 2024-06-07T03:45:24
• Duration

AST

stable 👎 FAIL

Output

IR

Compiled filesize 0 bytes (0 bytes)

Stats

• Started 2024-06-07T03:45:25
• Finished 2024-06-07T03:45:25
• Duration now

AST

2.0.4 👎 FAIL

Output

IR

Compiled filesize 0 bytes (0 bytes)

Stats

• Started 2024-06-07T03:45:25
• Finished 2024-06-07T03:45:25
• Duration now

AST

2.0.0 👎 FAIL

Output

IR

Compiled filesize 0 bytes (0 bytes)

Stats

• Started 2024-06-07T03:45:28
• Finished 2024-06-07T03:45:28
• Duration now

AST

1.6.20 👎 FAIL

Output

IR

Compiled filesize 0 bytes (0 bytes)

Stats

• Started 2024-06-07T03:45:31
• Finished 2024-06-07T03:45:31
• Duration now

AST

1.4.8 👎 FAIL

Output

IR

Compiled filesize 0 bytes (0 bytes)

Stats

• Started 2024-06-07T03:45:33
• Finished 2024-06-07T03:45:33
• Duration now

AST

1.2.18 👎 FAIL

Output

IR

Compiled filesize 0 bytes (0 bytes)

Stats

• Started 2024-06-07T03:45:35
• Finished 2024-06-07T03:45:35
• Duration

AST

1.0.10 👎 FAIL

Output

IR

Compiled filesize 0 bytes (0 bytes)

Stats

• Started 2024-06-07T03:45:37
• Finished 2024-06-07T03:45:37
• Duration now

AST

Stats

• GCC 11.4.0
• Clang 14.0.0
• NodeJS 20.3
• Created 2024-06-07T03:44:52Z
• Comments 1
• Commands nim c --run -d:nimDebug -d:nimDebugDlOpen -d:ssl -d:nimDisableCertificateValidation --forceBuild:on --colors:off --verbosity:0 --hints:off --lineTrace:off --nimcache:/home/runner/work/Nim/Nim --out:/home/runner/work/Nim/Nim/temp /home/runner/work/Nim/Nim/temp.nim

🤖 Bug found in 16 minutes bisecting 8 commits at 0 commits per second

[ringabout]

It crashed with 1.6.16 with --mm:orc -d:useMalloc

[alex65536]

Digging further into the compiler code, I noticed the following:

1. Here is the algorithm for copy-assignment of object variants. The main take here is that we move the old object into the new location and call wasMoved for the old object.
2. wasMoved is basically implemented here. Among other things, it calls resetLoc(), which in our case (code) generates nimZeroMem + default-initialization.
3. Zeroing memory is OK, but re-intialization with the default value for this moved-out object is actually the source of this bug.

I am not proficient in the compiler internals at all, so everything below this text in this comment is just a wild guess from a person who has seen the compiler code today for the first time:

• I am unsure whether zeroing memory is OK, because the next part of the code calls copy assign for each sub-variant, and I don't know how destructors of old values behave when they encounter zeroed memory (maybe everything is OK, but again, I don't know the compiler internals well).
• Another solution would probably be resetting the location before doing recursive assignment inside the case statement (not outside). It could be slower, but seems more reliable for me.

[alex65536]

Destructors are supposed to be written in such a way that 0'd memory indicates "this was moved"

OK, thank you, then zeroing is a nice idea indeed :)

And what happens if a =copy() implementation hooked by user receives zeroed memory as a destination? Or is there anything that prevents such thing from happening?

[beef331]

You call =destroy then copy the data over, there is no special logic for data that is 0'd =wasMoved should disarm =destroy.

[Araq]

Destructors are supposed to be written in such a way that 0'd memory indicates "this was moved"

Note that we're moving away from 0'd memory to the more abstract "=wasMoved/default state".