Skip to content
This repository

Mapnik segfault when linestring cross greenwhich #1132

Closed
yvecai opened this Issue March 17, 2012 · 12 comments

3 participants

yvecai Dane Springmeyer lightmare
yvecai

I have a segfault in mapnik when requesting postgis for line string that cross lon=0.
mapnik-config --git-revision
c95959c

Mapfile is here: https://gist.github.com/2058201

Icompiled renderd with 1x1 metatile to pinpoint the tile crashing the rendering chain, here is gdb output when I ask the particular tile 255 24 9 with render_list:

########################
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb3601b70 (LWP 3380)]
0xb7548d24 in mapnik::wkb_reader::read_linestring(boost::ptr_vector, boost::heap_clone_allocator, std::allocator >&) () from /usr/local/lib/libmapnik.so.2.1
(gdb) thread apply all bt

Thread 3 (Thread 0xb3e02b70 (LWP 3379)):
#0 0xb7781430 in __kernel_vsyscall ()
#1 0xb70d9936 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2 0xb70d9760 in sleep () from /lib/tls/i686/cmov/libc.so.6
#3 0x0804d39c in stats_writeout_thread (arg=0x0) at daemon.c:583
#4 0xb71a096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5 0xb710f98e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 2 (Thread 0xb3601b70 (LWP 3380)):
#0 0xb7548d24 in mapnik::wkb_reader::read_linestring(boost::ptr_vector, boost::heap_clone_allocator, std::allocator >&) () from /usr/local/lib/libmapnik.so.2.1
#1 0xb75491a9 in mapnik::wkb_reader::read(boost::ptr_vector, boost::heap_clone_allocator, std::allocator >&) () from /usr/local/lib/libmapnik.so.2.1
#2 0xb75472a3 in mapnik::geometry_utils::from_wkb(boost::ptr_vector, boost::heap_clone_allocator, std::allocator >&, char const*, unsigned int, mapnik::wkbFormat) ()
from /usr/local/lib/libmapnik.so.2.1
#3 0xb3e3cee9 in postgis_featureset::next() () from /usr/local/lib/mapnik/input/postgis.input
#4 0xb748a9eb in mapnik::feature_style_processormapnik::agg_renderer<mapnik::image_32 >::render_style(mapnik::layer const&, mapnik::agg_renderermapnik::image_32&, mapnik::feature_type_style*, std::string const&, boost::shared_ptrmapnik::Featureset, mapnik::proj_transform const&, double) () from /usr/local/lib/libmapnik.so.2.1
#5 0xb748c6bd in mapnik::feature_style_processormapnik::agg_renderer<mapnik::image_32 >::apply_to_layer(mapnik::layer const&, mapnik::agg_renderermapnik::image_32&, mapnik::projection const&, double, std::set to continue, or q to quit---
g, std::lessstd::string, std::allocatorstd::string >&) () from /usr/local/lib/libmapnik.so.2.1
#6 0xb748d346 in mapnik::feature_style_processormapnik::agg_renderer<mapnik::image_32 >::apply() ()
from /usr/local/lib/libmapnik.so.2.1
#7 0x0805084c in render (arg=0xbff60076) at gen_tile.cpp:446
#8 render_thread (arg=0xbff60076) at gen_tile.cpp:565
#9 0xb71a096e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#10 0xb710f98e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread 0xb5aaaab0 (LWP 3378)):
#0 0xb7781430 in __kernel_vsyscall ()
#1 0xb71088b1 in select () from /lib/tls/i686/cmov/libc.so.6
#2 0x0804e04b in process_loop (listen_fd=4) at daemon.c:455
#3 0x0804f5bb in main (argc=1, argv=0xbff94394) at daemon.c:1153
(gdb) q

########################

Dane Springmeyer
Owner

I'll like to try to replicate this but I'm finding mod_tile a pain to get running at the moment on os x. Would it be possible for you to try to reduce this testcase further?

Can you see if a simply python script that loads you map style and does map.zoom_to_box(-78271.51696402207,18080720.418688733,0.18158991.93565275), and then renders a tile still prompts the crash?

Also, are you using an entire planet dump imported with osm2pgsq, or just an extract? If an extract, which area? (and which specific download)

Dane Springmeyer
Owner

Also, it would be great if you could recompile mapnik with DEBUG on, like:

./configure DEBUG=True && make install

Then try to get another backtrace out and paste here. Ideally try to get 2-3 more backtraces out and paste them all.

Dane Springmeyer
Owner

ping @yvecai

yvecai
yvecai
yvecai

Hmm... of course you had corrected by yourself my comment above: tile 248-256 crosses greenwich and the equator at zoom 9.

yvecai

The issue seems to have disappeared with postgis2.0.0RC1.
I'll make a few more tests before closing.

yvecai
yvecai commented July 07, 2012

I can reproduce the issue with mapnik 2.0.1

Here is the debug from Mapnik via renderd:
https://gist.github.com/3068238
One of the faulty layer:
https://gist.github.com/3068260

Any idea

yvecai
yvecai commented July 08, 2012

I'm actually testing my tile server with random requests (10-20 /s).
After avoiding requests centered on (0,0) that always fail, I found the same crash for other tiles, like the one below.
If I restart renderd, request it again, it's ok.

https://gist.github.com/3069928

renderd: include/mapnik/coord_array.hpp:82: mapnik::coord_array::coord_type& mapnik::coord_array::operator [with T = mapnik::coord, mapnik::coord_array::coord_type = mapnik::coord]: Assertion `index<size_' failed.

Dane Springmeyer
Owner

Thanks. I think I've got a reduced test case. Rendering from this table with a single row that contains a multilinestring and an empty linestring can trigger the crash on reading a zero length line:

createdb -T template_postgis empty-line-in-multi
psql empty-line-in-multi
select ST_Collect('MULTILINESTRING ((10 10, 20 20, 10 40),(40 40, 30 30, 40 20, 30 10))'::geometry,'LINESTRING EMPTY'::geometry) as geom,'name'::text as name into empty;
<Map>
  <Style name="s">
    <Rule>
      <LineSymbolizer />
    </Rule>
  </Style>
  <Layer name="layer">
      <StyleName>s</StyleName>
      <Datasource>
          <Parameter name="type">postgis</Parameter>
          <Parameter name="dbname">empty-line-in-multi</Parameter>
          <Parameter name="table">empty</Parameter>
          <Parameter name="geometry_field">geom</Parameter>
      </Datasource>
  </Layer>
</Map>
lightmare

There are unchecked CoordinateArray accesses:

src/wkb.cpp:290:        CoordinateArray ar(num_points);
src/wkb.cpp-291-        read_coords(ar);
src/wkb.cpp-292-        line->move_to(ar[0].x, ar[0].y);
--
src/wkb.cpp:314:        CoordinateArray ar(num_points);
src/wkb.cpp-315-        read_coords_xyz(ar);
src/wkb.cpp-316-        line->move_to(ar[0].x, ar[0].y);
--
src/wkb.cpp:344:            CoordinateArray ar(num_points);
src/wkb.cpp-345-            read_coords(ar);
src/wkb.cpp-346-            poly->move_to(ar[0].x, ar[0].y);
--
src/wkb.cpp:374:            CoordinateArray ar(num_points);
src/wkb.cpp-375-            read_coords_xyz(ar);
src/wkb.cpp-376-            poly->move_to(ar[0].x, ar[0].y);
yvecai yvecai closed this July 08, 2012
yvecai
yvecai commented July 08, 2012

Yep, it seems that I have 3 empty cross-country ski trails in the Atlantic:
pistes-mapnik=# select st_astext(way),route_name from planet_osm_line where way && ST_MakeEnvelope(-10, -10,10, 10, 4326);
st_astext | route_name

------------------+------------------
LINESTRING EMPTY | Ravier
LINESTRING EMPTY | Bougaud
LINESTRING EMPTY | La Vue Des Alpes

No more crash if I delete them from the DB:

renderd[18328]: DEBUG: DONE TILE contours 9 256-263 256-263 in 0.111 seconds
renderd[18328]: DEBUG: Connection 0, fd 10 closed, now 0 left

Dane Springmeyer springmeyer referenced this issue from a commit July 20, 2012
Dane Springmeyer properly skip empty geometries - refs #1333 and #1305 an #1132
+ remove redundant ar.size() > 0 check
+ use std::auto_ptr<geometry_type> to avoid memory leaks and
  improve exception safety.
9c5dbc2
Dane Springmeyer springmeyer referenced this issue from a commit July 20, 2012
Dane Springmeyer properly skip empty geometries - refs #1333 and #1305 an #1132
+ remove redundant ar.size() > 0 check
+ use std::auto_ptr<geometry_type> to avoid memory leaks and
  improve exception safety.
3bd4a4d
Rich Wareham rjw57 referenced this issue from a commit July 31, 2012
Commit has since been removed from the repository and is no longer available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.