MobileNativeFoundation / MobileNativeFoundation/XCLogParser

Memory not released after ActivityParser.parseActivityLogInURL call

Open
#215 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Swift
Stars
1.9k
Forks
138
PR merge metrics
No merged PRs in 30d

Description

Hi, I would like to report an issue happening on 0.2.39.

The ActivityParser.parseActivityLogInURL call seems to leak a considerable amount of system memory indefinitely. Tried to workaround the problem using previous versions of the framework, but they all seem to have the same problem (tested up to 0.2.34). (Maybe problem due to recent version of Xcode toolchain?). While trying to break down internal calls, the problem seemed to be located on the Lexer.tokenize call.

I created this playground project where we simply try to decode some .xcactivitylog located under a certain path. Even using the autorelease pool, the program is not able to release the memory efficiently after parsing each log. At the end, all logs are parsed and a huge amount of memory is still in use (around 500MB for 6.6 MB of log files). While looking at the object graph, the objects leaked are of type CFString and CFString(Storage).

Steps to reproduce:

  • Download the sample project and change the derived data directory to your settings.
  • Run the application.
  • Check the memory consumption.
  • Click on "Fetch Logs".
  • Check the memory consumption and the object graph to see the leaks.

Context:
MacOS: Sonoma 14.6.1
Device: MacbookPro M1
Xcode: 15.4.0
XCLogParser installation: 0.2.39 (SPM)

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked XCLogParserLeak playground and reproduce the issue using ActivityParser.parseActivityLogInURL, then inspect the Lexer.tokenize call identified in the report. Compare memory usage and the object graph before and after parsing the sample .xcactivitylog files. Done means parsed logs no longer retain the reported CFString objects or substantial memory indefinitely.

Written by the indexing model from the issue text.

Assessment

Tech stack
swift
Domain
devtools
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.