[OSM-dev] Renderd problems.
jburgess777 at gmail.com
Tue Sep 28 18:29:52 BST 2010
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
> #7 0x00007fffea7bb0b6 in shape_io::read_polygon() () from
> 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
- 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.
More information about the dev