You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
Reporter: styno[at]hotmail.com [Submitted to the original trac issue database at 4.18pm, Friday, 23rd October 2009]
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.
Author: styno[at]hotmail.com [Added to the original trac issue at 9.50am, Tuesday, 10th November 2009]
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.
Author: woidrick [Added to the original trac issue at 8.08pm, Thursday, 12th November 2009]
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
Reporter: styno[at]hotmail.com
[Submitted to the original trac issue database at 4.18pm, Friday, 23rd October 2009]
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
The text was updated successfully, but these errors were encountered: