2KB memory leak found with Mac leaks tool

[eduardo-camacho]

ARIA SDK seems to be leaking memory while running Mac Office apps.

Repro steps:
Launch Word final stage/relese build to a blank doc (turn off docstage)
Close doc and create a new one
type "leaks {processID}

Expected Results:
No leaks reported from 1DS related code paths

Current Results:
Aria is leaking 2kb of memory

       20 (2.72K) ROOT CYCLE: 0x600000a90320 [160]
     CYCLE BACK TO 0x600000a90320 [160]
     15 (2.06K) ROOT CYCLE: 0x600000a90f00 [160]
        CYCLE BACK TO 0x600000a90320 [160]
        12 (1.59K) ROOT CYCLE: 0x600000a91b80 [160]
           8 (992 bytes) ROOT CYCLE: 0x600000a92120 [160]
              6 (672 bytes) ROOT CYCLE: 0x600000a93160 [160]
                 2 (288 bytes) ROOT CYCLE: 0x600000a93340 [160]
                    1 (128 bytes) 0x6000015c4580 [128]  length: 125  "/Users/nicktr/Library/Containers/com.microsoft.Word/Data/Library/Application Suppo..."
                 2 (192 bytes) ROOT CYCLE: 0x600000a93020 [160]
                    1 (32 bytes) 0x600003c3cb20 [32]  length: 27  "cacheMemorySizeLimitInBytes"
                 1 (32 bytes) 0x600003c3c880 [32]  length: 25  "cacheFileSizeLimitInBytes"
              1 (160 bytes) ROOT CYCLE: 0x600000a91fe0 [160]
           3 (480 bytes) ROOT CYCLE: 0x600000a914a0 [160]
              1 (160 bytes) ROOT CYCLE: 0x600000a90640 [160]
              1 (160 bytes) ROOT CYCLE: 0x600000a91040 [160]
        1 (160 bytes) ROOT CYCLE: 0x600000a90d20 [160]
        1 (160 bytes) ROOT CYCLE: 0x600000a92440 [160]
     2 (320 bytes) ROOT CYCLE: 0x600000a90be0 [160]
        CYCLE BACK TO 0x600000a90320 [160]
        1 (160 bytes) ROOT CYCLE: 0x600000a90a00 [160]
     1 (160 bytes) ROOT CYCLE: 0x600000a935c0 [160]
        CYCLE BACK TO 0x600000a90320 [160]
     1 (32 bytes) 0x600003c3cbe0 [32]  length: 25  "skipSqliteInitAndShutdown"

[maxgolov]

I have a few questions about the tooling used in this scenario:

• does creating a new doc - create a new process? i.e. does the tool catch the clean-up of global static variables.

Ref.: https://developer.apple.com/forums/thread/73588

Cit: The "Leaks" instrument is famous for being inccurate (both false positives and false negatives),
though I can't comment on the accuracy of the current version. It may simply be that the
particular way the singleton is stored is somehow confusing to Leaks.

We need to decide on the priority of it: is it possible to have a longer stress-test, with a larger document being open and edited for 10-15+ minutes, do you observe more than 2KB leak from SDK in this case? I'd say 2KB leak is minor and non-service impacting, thus lower priority. However, if we observe a larger leak in a stress - that is worrisome.

I'd also like to have this tackled in a different way: measuring the core layer only, i.e. standalone 1DS C++ SDK, no Obj-C projection - using tcmalloc (although results may differ). I am working in PR which will add it: #721

It is important to take a carefully weighted approach on this, avg of:

• "leaks" report; vs
• "tcmalloc" report.
  That is to avoid false-positives that are omnipresent with both of these tools.

Note that ILogger objects are leaky by-design:
#481
#489

That'd be adding up to at least 512+ bytes, if not 1KB out of 2K. This leak is "design intent" to avoid crashes in "use after free" scenarios.

[maxgolov]

Related to #634

[eduardo-camacho]

Word is single process, no new process is spin when creating a new document.

Please note Leaks currently reports leaks on few other places (not related to Aria) as well; leaked amount by Aria SDK is not severe, so bug is not high priority.

[maxgolov]

If you don't mind, I'll change the title :)

[larvacea]

Three of the strings called out in the example report are keys in a configuration object. I would certainly expect the configuration maps themselves to allocate before the first document open and outlive any number of documents in a single Word session. The OTel stack will have set configuration during liblet init, and won't do anything at all about tearing things down until liblet uninit, and this is consistent across all platforms (of course, since it's shared C++ code).