Opened 9 years ago

Last modified 9 years ago

#2386 new defect

Segfault on planet rebuild

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


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.


Change History (3)

comment:1 Changed 9 years ago by styno@…

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

} 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 styno@…

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.