Linking POCO C++ Library gives numerous memory leaks

I've just started trying to integrate the Poco C++ 开发者_JS百科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 gets rid of all the leaks (none of them are from my code). This happens even if I remove all Poco #includes from my c++ files.

I doubt there are really 51 memory leaks with Poco's Foundation (core) methods - searching their forums didn't reveal anything, and I'm sure other users would notice something this glaring. I think it is more likely a problem with how I'm linking to Poco?

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

Any suggestions on what the problem could be are most welcome! The only thing I can think of is that I'm not linking Poco correctly.

Possibly related: The OP at c-poco-lib-linking-error-when-trying-static-linking-vs9-express mentions something about "Added Preprocessor flags Foundation_EXPORTS POCO_STATIC PCRE_STATIC" - what would that do? I can't see any information on the Poco reference pages about how to correctly link Poco.

---

You don't say what tool is telling you that you have memory leaks, but I'm going to presume that it is valgrind since you are on Ubuntu.

If the leaks occur even if you aren't calling any POCO methods, then it is likely that these are one-off allocations occurring during the static initialization of the POCO library that for whatever reason are not being torn down later.

While that isn't particularly great behavior on the part of a library, it is not fatal. The leaks that you should be worried about are ones that will occur repeatedly and will gradually consume memory.

I'd recommend using valgrind --gen-suppressions=all to generate suppressions for the one time leaks for now (especially good that you aren't calling any POCO methods). Then, have a look at the POCO library and see if you can figure out why these allocations aren't being unwound at .fini time. If you can, great, let the POCO people have your fixes, and then you can take down your suppression entries. If not, leave them in so these 'false positives' don't interfere with finding truly harmful memory leaks in your code.

---

Some objects must be deallocated by calling method "release"

Below is an extract from a doc poco

" DOMObject defines the rules for memory management in this implementation of the DOM. Violation of these rules, which are outlined in the following, results in memory leaks or dangling pointers.

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