Binding a POCO C ++ library gives numerous memory leaks

Question

I just started trying to integrate Poco C ++ Library with our game engine, however every time I link /usr/lib/libPocoFoundation.so my program suddenly has 51 memory leaks. Removing the link option eliminates all the leaks (none of them are from my code). This happens even if I delete all the Poco #include from my C ++ files.

I doubt that there really is a 51 memory leak using the Poco Foundation (core) methods - looking for their forums did not find anything, and I'm sure other users will notice something like that. I think this is more of a problem with how I contact Poco?

I'm on Ubuntu 11 using Code :: Blocks for IDE, g ++ 4.5.2 to build and extract Poco 1.3.6p1-1build1 from ubuntu ppa ( sudo apt-get install libpoco-dev libpoco-doc ).

Any suggestions on what might be the problem are welcome! The only thing I can think of is that I am not binding Poco correctly.

Perhaps related: the OP in c-poco-lib-linking-error-when-trying-static-linking-vs9-express mentions something about "Added Preprocessor Foundation_EXPORTS POCO_STATIC PCRE_STATIC flags" - what would it do? I do not see any information on Poco's help pages on how to properly link Poco.

Answer 1

You are not saying which tool tells you that you have a memory leak, but I assume it is valgrind, since you are on Ubuntu.

If leaks occur even if you do not call any POCO methods, then it is likely that these are one-time distributions that occur during the static initialization of the POCO library, which for some reason do not break later.

Although this is not a particularly remarkable behavior on the part of the library, it is not fatal. The things that concern you are those that will occur repeatedly and will gradually consume memory.

I would recommend using valgrind --gen-suppressions=all to create suppressions for one-time leaks at the moment (it is especially good that you do not call any POCO methods). Then look at the POCO library and see if you can understand why these distributions do not unwind at .fini time. If you can, great, let the POCO people have your corrections, and then you can remove your suppression notes. If not, leave them so that these “false positives” do not interfere with finding really harmful memory leaks in your code.

Answer 2

Some objects must be freed by calling the release method

Below are excerpts from doc poco

"DOMObject defines memory management rules in this DOM implementation. Violation of these rules, which are described below, results in memory leaks or dangling pointers.

Each object created by a new one or using the factory method (for example, Document :: create *) must be released with a call to release () or autoRelease () when it is no longer needed. "