Is there a memory leak?

[rspiwoks]

Hi,

I am using yaml-cpp for parsing/emitting YAML because it is very simple and flexible as it comes with many predefined type conversions which can easily be extended.
However, the behaviour of the underlying shared memory management is surprising to say the least: in a simple example as the following, the memory usage will increase out of bounds (several GBytes before the program gets killed).

YAML::Node node;
node["test"] = 42;
for(auto i=0; i<10000000; ++i) {
node["test"] = 42;
}

There is a live repro here: https://godbolt.org/z/4PWezz16r. I first issued an open question on stackoverflow here: https://stackoverflow.com/staging-ground/79939206

While the example is rather artificial, we have cases where we read and override configuration data (YAML) many times, and having such behaviour as described above makes us hesitate to use yaml-cpp.

Thanks for any hints on this. Cheers,
Ralf

[MarekR22]

Here is prove that this is not memory fragmentation issue.
You can see memory linearly with iteration unless node is recreated.

I'm guessing some cached nodes are not reclaimed by a code and get accumulated.

[SGSSGene]

Hi @rspiwoks, thanks for the report!

This is an issue others also have reported. I am not sure where it comes from, but also have/had no time to investigate it.
For reference here are the tickets that I think are talking about the same issue:

• memory leak #944
• Rising memory consumption in this snippet #691
• Potential memory leak or misusage of API #534
• unbounded memory usage when repeatedly calling Node::operator= #232
• Attempt to fix the memory leak mentioned in #691 #775 (a PR that tries to fix it)

Currently, we do not have the capacity to tackle this issue, but we are open to PRs working on this.

[jbeder]

It's rude to paste an AI-generated analysis. If we want to, we can just as easily ask an LLM. Please don't do that again (not just here, but any open source repos also).

[jbeder]

No worries, thank you for understanding!

[rspiwoks]

Hi Jesse,

Thanks for your reply.

I really like yamlcpp because it has an intuitive API, has a lot of type conversions which can easiliy be extended to new user types, and has line and column tracking for every Node when reading from file.

But I am very puzzled now and don't know what to do. I could ignore the memory issue hoping that it would not create too big a memory footprint for our applications. But I don't really like that solution.
I could try to have a closer look at the code, but I have not much time myself, in particular, this week and next. Anyway, I would really not know where to start.

Cheers,
Ralf.

[SGSSGene]

@rspiworks Your concerns are understandable.
You might also want to take a look at rapidyaml. I haven't used it, so I can't say what the issues are there, but it seems to have somewhat similar API (yaml-cpp also has its own surprises).
Maybe that is also a good fit for you new project.