Home/ Questions/Q 6019301
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T03:24:08+00:00

I’ve just started trying to integrate the Poco C++ Library with our game engine,

  • 0

I’ve just started trying to integrate the 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 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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0