Opened 10 years ago

Last modified 9 years ago

#2386 new defect

Segfault on planet rebuild

Reported by: Lambertus Owned by: ddean@…
Priority: blocker Milestone:
Component: gosmore Version:
Keywords: segmentation fault rebuild database Cc:

Description

While rebuilding a new database using my Eurasia planet extract Gosmore crashed (version 18268). Testing with the Benelux extract [1] Gosmore also crashes with a segmentation fault quite early in the process.

[1] http://planet.openstreetmap.nl/planet-benelux-latest.osm.gz

Change History (3)

comment:1 Changed 9 years ago by Lambertus

Gosmore also crashes while parsing the unmodified planet file, so it's not caused by Osmosis on bbox extraction. GDB reports segfault in RebuildPak?(). This appears to be a type definition problem which triggers segfaults in 64bit systems.

Types like long long are not really portable.

comment:2 Changed 9 years ago by woidrick

For me it segfaults in line 1606 of libgosm.cpp

i did add

if (l != 0) {

before that line and

} else newln = 0;

after that line

i'm not a programmer, so i'm is not sure if it will produce a broken database but gosmore runs for 10 minutes without segfaults - longest time ever sorry, can't check for longer - it is late

programmers should check why variable l is sometimes zero

comment:3 in reply to:  description Changed 9 years ago by Lambertus

One problem is solved by reinstating line 1958 in libgosm.cpp:

Block lost nodes with if (ndItr->lat == INT_MIN) continue;

But now it seems to enter an infinite loop in step 6.

Note: See TracTickets for help on using tickets.