segfault in shape.input in release mode only #1401

Open
gravitystorm opened this Issue Aug 16, 2012 · 3 comments

Comments

Projects
None yet
2 participants
@gravitystorm

I can trigger segfaults in mapnik 2.1-stable (commit 2375fcd ), but annoyingly only in release mode. Building with ./configure DEBUG=True and testing in the same place doesn't trigger the segfault.

I doubt these lines from kern.log are of much use, but here goes:

Aug 16 14:00:48 Ubuntu-1204-precise-64-minimal kernel: [167800.184997] renderd[31427]: segfault at 7fcf4d852000 ip 00007fcf6ac05ba1 sp 00007fcf68f35350 error 4 in shape.input[7fcf6abcf000+42000]
Aug 16 14:01:07 Ubuntu-1204-precise-64-minimal kernel: [167819.288407] renderd[31879]: segfault at 7f232c0a0000 ip 00007f235607cba1 sp 00007f23543ac350 error 4 in shape.input[7f2356046000+42000]
Aug 16 14:01:38 Ubuntu-1204-precise-64-minimal kernel: [167849.939318] renderd[31887]: segfault at 7f61f0000000 ip 00007f6215d85ba1 sp 00007f62138b4350 error 4 in shape.input[7f6215d4f000+42000]
Aug 16 14:02:04 Ubuntu-1204-precise-64-minimal kernel: [167875.782985] renderd[31891]: segfault at 7facfd5ee000 ip 00007fad1c779ba1 sp 00007fad1b2aa350 error 4
Aug 16 14:02:04 Ubuntu-1204-precise-64-minimal kernel: [167875.782994] renderd[31893]: segfault at 7facfd5ee000 ip 00007fad1c779ba1 sp 00007fad1a2a8350 error 4 in shape.input[7fad1c743000+42000] in shape.input[7fad1c743000+42000]
Aug 16 14:02:04 Ubuntu-1204-precise-64-minimal kernel: [167875.783009] 
Aug 16 15:46:54 Ubuntu-1204-precise-64-minimal kernel: [174162.388074] renderd[13076]: segfault at 7f33ec0a0000 ip 00007f3413443ba1 sp 00007f3412775350 error 4 in shape.input[7f341340d000+42000]
Aug 16 15:47:09 Ubuntu-1204-precise-64-minimal kernel: [174177.340144] renderd[13084]: segfault at 7f9a700a0000 ip 00007f9a97a4eba1 sp 00007f9a95d7e350 error 4 in shape.input[7f9a97a18000+42000]

I'm afraid the data and stylesheets aren't available to share. Is there anything else that I could do to help debug?

I'm using renderd, on ubuntu 12.04 with boost 1.48 , and recompiling renderd after each mapnik recompile.

@springmeyer

This comment has been minimized.

Show comment Hide comment
@springmeyer

springmeyer Aug 16, 2012

Owner

I'd guess it is some geometry which is being parsed wrong, or is corrupt.

First thing I would try would be to isolate the shapefile causing the crash and then make a copy of it with ogr2ogr. Check and see if the resulting file(s) are identical. Sometimes QGIS and ArcGIS (at least) can author invalid shapefiles and copying them with ogr2ogr basically cleans them and things start to work perfectly again with mapnik.

If that does not fix it, then next thing is we need to get a gdb backtrace.

Owner

springmeyer commented Aug 16, 2012

I'd guess it is some geometry which is being parsed wrong, or is corrupt.

First thing I would try would be to isolate the shapefile causing the crash and then make a copy of it with ogr2ogr. Check and see if the resulting file(s) are identical. Sometimes QGIS and ArcGIS (at least) can author invalid shapefiles and copying them with ogr2ogr basically cleans them and things start to work perfectly again with mapnik.

If that does not fix it, then next thing is we need to get a gdb backtrace.

@gravitystorm

This comment has been minimized.

Show comment Hide comment
@gravitystorm

gravitystorm Aug 21, 2012

So the proximate cause of this appears to have been using a giant (10Gb) shapefile, which I didn't realise wasn't supported. I'm not sure whether this ticket should be closed, or whether mapnik should refuse to handle large shapefiles more gracefully :-).

So the proximate cause of this appears to have been using a giant (10Gb) shapefile, which I didn't realise wasn't supported. I'm not sure whether this ticket should be closed, or whether mapnik should refuse to handle large shapefiles more gracefully :-).

@springmeyer

This comment has been minimized.

Show comment Hide comment
@springmeyer

springmeyer Aug 22, 2012

Owner

Handling more gracefully by throwing if the size of any one shapefile part is >= 2 GB sounds like a good idea. I'll take a look at doing this on a rainy day :)

Owner

springmeyer commented Aug 22, 2012

Handling more gracefully by throwing if the size of any one shapefile part is >= 2 GB sounds like a good idea. I'll take a look at doing this on a rainy day :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment