Mirror of forum.nim-lang.org

10226 :: May bug with ``ptr ref`` combine closure?

• slangmgh (orginal) [2023-05-26T06:18:22+02:00] view original

  Look at the following code:

  ## nim c --mm:refc a.nim
  type
     Foo = ref object
        a: int
  
  proc unsafe_ref_count(x: ref): int =
     let p = cast[ptr UncheckedArray[int]](x)
     p[-2] shr 3
  
  proc main(px: ptr Foo) =
     let x = px[]
     proc p1() =
        inc x.a
     
     echo "ref in  ", x.unsafe_ref_count
     p1()
     echo "ref out ", x.unsafe_ref_count
  
  when isMainModule:
     var x = Foo(a: 5)
     for _ in 1..5:
        main(x.addr)
     
     echo "ref last ", x.unsafe_ref_count
  Run

  compile the code with --mm:refc and give the following output:

  
  ref in  2
  ref out 2
  ref in  3
  ref out 3
  ref in  4
  ref out 4
  ref in  5
  ref out 5
  ref in  6
  ref out 6
  ref last 6
  Run

  If I change the closure proc p1() to template p1(), then the output is:

  
  ref in  1
  ref out 1
  ref in  1
  ref out 1
  ref in  1
  ref out 1
  ref in  1
  ref out 1
  ref in  1
  ref out 1
  ref last 1
  Run

  These is the expected behaviour.

---

• Araq (orginal) [2023-05-26T06:26:16+02:00] view original

  There is no bug here, you capture the x in p1 causing a refcount increase. The refc is lazy and after 5 iterations these closures have not yet been collected thus the refcount doesn't drop. Eventually the closures will be collected causing the refcount to drop.

---

• slangmgh (orginal) [2023-05-26T07:58:39+02:00] view original

  Thank you, that make sence. :)

  I have a real world bug related this, it is troubled me for long time, please give me some hints if possible.

  The real world program like this:

  I have an big ref object named as BigObj, which I pass to several children thread with pointer, because I don't want it is to be copied. The BigObj is readonly both in main thread and children thread, and main thread will wait till all children thread finish there job. Now the problem comes, in the child thread, If I use closure to access the BigObj, after some iteration, the BigObj is freeed(The inner data changed so I think the only possible reason is it be freeed); if I use template, the program works fine. If I use the closure and add an GC_Ref(BigObj) call, the program works fine too.

  So, what is possible reason for this?

---

• demotomohiro (orginal) [2023-05-26T09:09:13+02:00] view original

  I guess, when you use closure in children threads, they increase or decrease the reference counter of the BigObj. As that reference counter is not atomic counter, increasing/decreasing it from multiple threads doesn't work correctly.

---

• slangmgh (orginal) [2023-05-26T09:15:07+02:00] view original

  As the example above show, the ref count only increased, rather than decreased, so it is will not be freeed because of ref count is zero. But as I said, add GC_Ref(BigObj) sure prevent the BigObj from be freeed.

---

• demotomohiro (orginal) [2023-05-26T11:16:50+02:00] view original

  I thought threads on your code might increase the ref count of the BigObj at same time. Increasing an int value from multiple threads is undefined behavior unless it is atomic or use lock. So the ref count is never changed while threads are running or you use a lock when increasing the ref count?

---

• slangmgh (orginal) [2023-05-26T15:50:11+02:00] view original

  Good point!

---

• slangmgh (orginal) [2023-05-26T16:02:17+02:00] view original

  You are very correct. I change the incRef/decRef to atomicInc/atomicDec in gc.nim, then the program work fine. :)

  Thank you.

---

• Araq (orginal) [2023-05-26T16:29:14+02:00] view original

  On devel you can compile with --mm:atomicArc.

---

• slangmgh (orginal) [2023-05-26T16:30:40+02:00] view original

  So this is the reason why share an ref object between threads is dangerous even if the ref object is read only. But with atomicRef should be fine with read only ref object.

---