On Tue, 2010-09-28 at 09:58 -0500, Samir Faci (Dev) wrote: > (gdb) bt > #0 0x00007ffff6f5da75 in raise () from /lib/libc.so.6 > #1 0x00007ffff6f615c0 in abort () from /lib/libc.so.6 > #2 0x00007ffff78138e5 in __gnu_cxx::__verbose_terminate_handler() () > from /usr/lib/libstdc++.so.6 > #3 0x00007ffff7811d16 in ?? () from /usr/lib/libstdc++.so.6 > #4 0x00007ffff7811d43 in std::terminate() () from /usr/lib/libstdc++.so.6 > #5 0x00007ffff7811e3e in __cxa_throw () from /usr/lib/libstdc++.so.6 > #6 0x00007ffff77acf42 in std::__throw_bad_alloc() () from > /usr/lib/libstdc++.so.6 > #7 0x00007fffea7bb0b6 in shape_io::read_polygon() () from > /usr/lib/mapnik/0.7/input/shape.input
> now.. I'm presuming this isn't necessarily a bug with renderd as much > as some funky data that it can't handle. I was wondering if anyone > had any suggestion as to what my next step is to try to track down > what's causing the crash. I presume that if I do a fresh planet load > it'll probably fix the problem. I would like to know though what's > causing it and maybe find a way to avoid or account for the issue in > the future. >From the backtrace above, the crash occurs when it is reading a shapefile, probably the processed_p.shp which only starts rendering at zoom 10+ (the "coast-poly" layer/style). I expect the error would stop if you turned off that layer. The first things I would look at are: - Maybe the shapefile index does not match the shapefile and you need to run the 'shapeindex' on processed_p.shp. - Perhaps your shape.input plugin does not match the libmapnik you are using. - Have you compiled mapnik as a 64 bit library? The processed_p shapefile is large and with multiple threads you can easily run out of virtual address space on a 32 bit executable even if you have plenty of physical RAM available. Importing the planet again it very unlikely to fix the problem. Jon _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
