Opened 11 years ago

Closed 3 months ago

#2386 closed defect (wontfix)

Segfault on planet rebuild

Reported by: Lambertus 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 (4)

comment:1 Changed 11 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 11 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 11 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.

comment:4 Changed 3 months ago by mmd

Resolution: wontfix
Status: newclosed

Gosmore project is no longer active, closing.

Note: See TracTickets for help on using tickets.