[pgrouting-dev] [pgrouting] need help with std::bad_alloc issue

[Alec Gosse]

Hello all,

In case it helps:

I was having problems with C++ memory allocations seeming to clobber memory allocated in the C code, e.g. the array of edges from the SPI query. When the C++ vector of nodes was resized in my version of the cpp_core function in bd_astar, the array of edges from C turned to garbage. I got around this by allocating another array of edges in the C++ code and copying the data prior to the vector resize, but I assume something improper still lurks beneath the surface. 

If it's relevant, I was also unable to use openMP because it crashes at the first new[] of a C++ copy constructor when making a copy of the routing class for each thread. With just one thread, the copy constructor is still used and works fine. I was able to route ~500k trips in less than an hour using this code single threaded but with multiple simultaneous queries, so it does "generally" work. These behaviors seem the same on Mac 10.8 and Ubuntu 13, both Postgres 9.2.4.

I did see a post that it's possible to run the entire postgres process under valgrind to get more info on memory, but I haven't had the time to attempt it.

Alec



On Jun 11, 2013, at 10:33 AM, Stephen Woodbridge <woodbri at swoodbridge.com> wrote:

> Hi devs,
> 
> I have run into a strange problem with some pgrouting functions that you guys might have already seen in postgis.
> 
> We have stored procedures that are C and C++ and in general they work fine, but if I create a database, connect to it, create extensions and run some commands I get std::bad_alloc error. If I simply reconnect to the database, the same command does not generate an error, and, in fact, if I reconnect after installing the extension, I never get this error.
> 
> I have traced this down to the particular statement that is throwing the error, but there is nothing unique or particular about it. And we have seen this behavior in multiple commands.
> 
> So I have to conclude that:
> 
> 1. we use the same pattern for most of our commands so that might be flawed in some basic way regarding memory
> 
> 2. that there  is something strange about create extension in that the libraries are not getting initialized correctly (or completely?) until a connection is made. We are trying to verify this is or is not unique to pg 9.2.
> 
> 3. pgrouting installs multiple shared libraries in our extension and maybe postgresql assumes there is only going to be one shared library
> 
> 4. or something else totally different that we are missing
> 
> So has anyone seen anything like this with postgis code?
> Any thoughts on what this might be? or how to run it down?
> 
> I did post post a inquiry to the postgresql list and Tom responded with not enough information and to compile the server with --enable-cassert which I did (assuming my Debian recompile worked correctly), but since this is a C++ error and not a postgresql palloc issue we have not seen and cassert errors.
> 
> Thoughts?
> 
> -Steve
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev