[postgis-devel] [pgrouting] need help with std::bad_alloc issue

[Sandro Santilli]

On Wed, Jun 12, 2013 at 04:56:22PM -0400, Stephen Woodbridge wrote:
> Interestingly, I just traced down another of these issues. I turns
> out this one was another in the family of std::vector problems. I
> resolved it by adding my_vector.reserve(my_size) to the code before
> we tried to add anything to the vector using a vector.push_back(...)
> 
> While it is probably good practice to do this, it is not require and
> the code works fine in a standalone command line program. I'm not
> very knowledgeable in C++ and how it deals with creating objects,
> etc, but this feels a lot like a bug in the create extension
> facility where it missing a step of calling the c++ library
> initialization code when the shared library is loaded and that some
> how my adding the call to reserve() method initializes what should
> have gotten initialized before and does get initialized when I
> re-connect to the database and the connection code makes sure all my
> libraries are loaded and initialized. But this is just my wild guess
> based on what I'm observing and I could be way off base.

Reserving some memory might be just perturbating uninitialized memory
enough to postpone the problem. These hard-to-track bugs are often due
to using uninitialized memory. Valgrind may not know because the backend
process still is the owner of the whole memory block, but doesn't
consider it taken from your specific code. Building with --enable-cassert
_might_ help with that (but I'm not sure).

If you use GCC you may also try to export the env variable 
GLIBCXX_FORCE_NEW (for GCC 3.4+) to reduce caching in the STL.

Your goal is to consistently reproduce the bug, not to further hide it,
so the less you .reserve the better...

--strk;