Uploaded image for project: 'ROOT'
  1. ROOT
  2. ROOT-8145

TMethodCall::InitWithPrototype keeps accumulating memory on successive calls

    XMLWordPrintable

    Details

    • Development:

      Description

      We discovered in one of the ATLAS analysis codes a little while ago, that one needs to be very careful with calling TMethodCall::InitWithPrototype too many times on the same object.

      Attached is an example demonstrating the issue. The code just repeatedly initialises a TMethodCall object to point to the TString::Data function. (I just randomly chose a builtin type for this.) With "enough" calls, the memory of the application keeps rising. On my Mac laptop I got:

      Info in <printMemoryUsage>: Memory usage in step "startup": RSS = 11756 kB, VSS = 38984 kB
      Info in <printMemoryUsage>: Memory usage in step "iteration 0": RSS = 93896 kB, VSS = 66728 kB
      Info in <printMemoryUsage>: Memory usage in step "iteration 100000": RSS = 95312 kB, VSS = 74920 kB
      Info in <printMemoryUsage>: Memory usage in step "iteration 200000": RSS = 96876 kB, VSS = 74920 kB
      Info in <printMemoryUsage>: Memory usage in step "iteration 300000": RSS = 98444 kB, VSS = 74920 kB
      Info in <printMemoryUsage>: Memory usage in step "iteration 400000": RSS = 99892 kB, VSS = 75304 kB
      Info in <printMemoryUsage>: Memory usage in step "iteration 500000": RSS = 101452 kB, VSS = 76840 kB
      Info in <printMemoryUsage>: Memory usage in step "iteration 600000": RSS = 103016 kB, VSS = 78376 kB
      Info in <printMemoryUsage>: Memory usage in step "iteration 700000": RSS = 104584 kB, VSS = 79916 kB
      Info in <printMemoryUsage>: Memory usage in step "iteration 800000": RSS = 106144 kB, VSS = 81452 kB
      Info in <printMemoryUsage>: Memory usage in step "iteration 900000": RSS = 107712 kB, VSS = 83116 kB
      Info in <printMemoryUsage>: Memory usage in step "finalize": RSS = 109280 kB, VSS = 84660 kB

      The really ugly thing about it is that it's not a memory leak. So Valgrind is absolutely blind to this issue. (Took me a while to figure out why all of our analysis jobs kept using more memory after a bigger code update...)

      For now of course we modified our code not to call this function as much, and so avoid the issue. But it would be good to understand where this memory growth is coming from.

      Cheers,
      Attila

        Attachments

          Activity

            People

            • Assignee:
              pcanal Philippe Canal
              Reporter:
              akraszna Attila Krasznahorkay
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: