Mirror of forum.nim-lang.org

11045 :: How to detect (and report) reference cycles?

• lou15b (orginal) [2024-02-19T22:55:46+01:00] view original

  I have a fairly large existing code base (~30k loc) that contains reference cycles, and I want to make that code suitable for use using mm:arc or mm:atomicArc. So I need to break those cycles, probably mostly by changing certain ref variables to cursor variabless.

  In order to do that I need to reliably detect and locate each cycle, break it, detect/locate the next cycle, and so on until all have been resolved.

  Is there some tool and/or procedure that I can use for this purpose?

---

• Araq (orginal) [2024-02-21T16:58:50+01:00] view original

  Via the help of this PR: https://github.com/nim-lang/Nim/pull/23272

---

• lou15b (orginal) [2024-02-21T17:55:47+01:00] view original

  When I asked this question I had a feeling that there may not be an easy answer. It looks like that intuition was correct.

  Thanks @Araq, your PR would be a very big help.

  Here is a procedure that I came up with based on my searching so far (unfortunately nested bullets has glitches, at least in the edit preview):

  • Compose an exhaustive (or reasonably representative) set of use cases.
  • For each use case (or set of use cases):
    • Write a test program that exercises the use case(s).
    • If the Nim compiler includes the above PR, then compile and execute the program with the switch for ORC stats turned on.
    • If the stats show a non-zero of objects collected by the cyclic collector, or if the Nim compiler does not include the PR (i.e. today):

      • Compile the program using --mm:atomicArc -d:useMalloc. (atomicArc to allow for use cases that involve multithreading)
      • Execute the program using valgrind with the following arguments:
        • --leak-check=full
        • --show-leak-kinds=all
        • --verbose
        • and optionally --log-file=valgrind-out.txt if the output is large.
      • Inspect the ouput. Any memory leak is likely (but not necessarily) caused by a reference cycle.
      • Track down and fix each leak. If it is a reference cycle then break it.
      • Repeat the test until no leaks detected.

    • If the Nim compiler includes the PR, then compile and execute the program with the switch for ORC stats turned on and validate that the cycle collector's object count is zero.

  A laborious process, but the PR does give us a way to be reasonably confident of validating when all (or almost all) cycles have been fixed, and detecting when they haven't.

---