I've been poking at this for a while, so I figured I should ask much brighter people about the topic.
I downloaded and applied a recent planet file using slim mode. planet-100922.osm.bz2 MD5: 04327dc409fe4a2a23130ec265fe6703 When I tried to use render_list to regenerate all the usual tiles (that I care about 0-13). It gets to up to lvl 10 then almost dies. When I tried to run just level 10 it dies almost immediately. So, I recompiled renderd and render_list with debugging symbols from: http://github.com/openstreetmap/mod_tile, attached to it using gdb and ran renderd in the foreground. output: renderd[8409]: DEBUG: Got command RenderBulk fd(20) xml(default), z(10), x(0), y(232) renderd[8409]: DEBUG: DONE TILE default 10 0-7 160-167 renderd[8409]: DEBUG: DONE TILE default 10 0-7 160-167 in 0.216 seconds renderd[8409]: DEBUG: Got command RenderBulk fd(23) xml(default), z(10), x(0), y(240) terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe70a1710 (LWP 8417)] 0x00007ffff6f5da75 in raise () from /lib/libc.so.6 usually I see that message when the system is low on memory, but in this case, I have about 23 gigs of RAM unused, so I don't think its an issue with the system ram. okay.. so backtrace: (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 #8 0x00007fffea7b7d58 in shape_index_featureset<mapnik::filter_in_box>::next() () from /usr/lib/mapnik/0.7/input/shape.input #9 0x000000000040d550 in mapnik::feature_style_processor<mapnik::agg_renderer<mapnik::Image32> >::apply_to_layer (this=<value optimized out>, lay=<value optimized out>, p=..., proj0=<value optimized out>, scale_denom=<value optimized out>) at /usr/include/mapnik/feature_style_processor.hpp:208 #10 0x000000000040b154 in mapnik::feature_style_processor<mapnik::agg_renderer<mapnik::Image32> >::apply (m=<value optimized out>, xmlname=<value optimized out>, prj=<value optimized out>, x=<value optimized out>, y=<value optimized out>, z=<value optimized out>, size=8, tiles=...) at /usr/include/mapnik/feature_style_processor.hpp:99 #11 render (m=<value optimized out>, xmlname=<value optimized out>, prj=<value optimized out>, x=<value optimized out>, y=<value optimized out>, z=<value optimized out>, size=8, tiles=...) at gen_tile.cpp:437 #12 0x000000000040ba1b in render_thread (arg=<value optimized out>) at gen_tile.cpp:555 #13 0x00007ffff6d139ca in start_thread () from /lib/libpthread.so.0 #14 0x00007ffff70106fd in clone () from /lib/libc.so.6 #15 0x0000000000000000 in ?? () lines that were marked by the BT. http://github.com/openstreetmap/mod_tile/blob/master/gen_tile.cpp#L441 http://github.com/openstreetmap/mod_tile/blob/master/gen_tile.cpp#L555 I'm rendering using the following syntax: time /usr/bin/render_list -v --all -n 7 --socket=/var/run/renderd/renderd.sock --min-zoom=10 --max-zoom=10 and this is how long it lasts before it dies: real 0m0.869s user 0m0.000s sys 0m0.010s So.. since that's giving me problems.. I ran some things manually: echo "0 232 10" | /usr/bin/render_list -v -n 1 --socket=/var/run/renderd/renderd.sock ## works fine. echo "0 248 10" | /usr/bin/render_list -v -n 1 --socket=/var/run/renderd/renderd.sock ## instant crash echo "0 240 10" | /usr/bin/render_list -v -n 1 --socket=/var/run/renderd/renderd.sock ## instant crash 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. also: loading syntax: osm2pgsql --slim -H localhost -U osmuser -W -d gis /tiles/Archives/planet-100922.osm.bz2 -- Samir Faci *insert title* fortune | cowsay -f /usr/share/cows/tux.cow _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
