osm2pgsql stürzt ab

Hi,

mein osm2pgsql (0.84) stürzt beim Import des Planeten (planet-140226.osm.pbf) in die Datenbank (Postgresql 9.3, PostGIS 2.1) ab. Es werden noch die Nodes und Ways prozessiert, beim Bearbeiten der Relationen kommt es dann zum Absturz.

Hier mal der letzte Output vor dem Absturz …

> Reading in file: planet-140226.osm.pbf Processing: Node(2219907k
> 62.8k/s) Way(219165k 7.62k/s)
Relation(741130 33.82/s)Segmentation fault (core dumped)

Der Absturz passiert immer an der selben Relationsnr. Den Dump habe ich mit seinem MD5 verglichen und da gibt es keine Unterschiede, also liegt wohl kein Fehler beim Download vor. Wenn ich den Coredump mit GDB untersuche und den Backtrace ansehe komme ich leider auch nicht weiter.

(gdb) bt
#0  0x000000000040d0e9 in std::vector<std::string, std::allocator<std::string> >::_M_insert_aux ()
#1  0x000000000040d419 in std::vector<std::string, std::allocator<std::string> >::_M_insert_aux ()
#2  0x000000000041be7e in std::vector<std::string, std::allocator<std::string> >::_M_insert_aux ()
#3  0x00000000004140e3 in std::vector<std::string, std::allocator<std::string> >::_M_insert_aux ()
#4  0x000000000040de5e in std::vector<std::string, std::allocator<std::string> >::_M_insert_aux ()
#5  0x000000000040e758 in std::vector<std::string, std::allocator<std::string> >::_M_insert_aux ()
#6  0x000000000040aa65 in std::vector<std::string, std::allocator<std::string> >::_M_insert_aux ()
#7  0x0000000000420706 in std::vector<std::string, std::allocator<std::string> >::_M_insert_aux ()
#8  0x0000000000420cc4 in std::vector<std::string, std::allocator<std::string> >::_M_insert_aux ()
#9  0x000000000042106c in std::vector<std::string, std::allocator<std::string> >::_M_insert_aux ()
#10 0x000000000041229c in std::vector<std::string, std::allocator<std::string> >::_M_insert_aux ()
#11 0x0000000000405451 in ?? ()
#12 0x000000080064c000 in ?? ()
#13 0x0000000000000000 in ?? ()

Das ganze unter FreeBSD 9.2, und hier das Kommando zum Import (Copy&Paste aus meinem Shellscript, dem nur das PBF als Parameter übergeben wird):

#!/bin/sh

OSM2PGSQL="/usr/local/bin/osm2pgsql"
NUM="8"
CACHE="12000"
STRAT="optimized"
NODEFILE="/usr/home/brfr/osm/node.cache"
PROJ="3857"
STYLE="/usr/home/brfr/osm/default.style"
HOST="localhost"
DB="osm"
USER="postgres"
PREFIX="planet_osm"

$OSM2PGSQL \
    --create \
    --number-processes $NUM \
    --slim \
    --flat-nodes $NODEFILE \
    --cache $CACHE \
    --cache-strategy $STRAT \
    --style $STYLE \
    --prefix $PREFIX \
    --proj $PROJ \
    --host $HOST \
    --database $DB \
    --username $USER \
    --hstore-all \
    --hstore-add-index \
    --verbose \
    $1

Hat da irgendjemand eine Idee? Mir ist das ganze suspekt, denn Dumps von Europe und Luxembourg gehen, also funktioniert das ganze prinzipiell …

mach doch mal osm2pgsql --version und schau den output an. meiner lautet

osm2pgsql --version
osm2pgsql SVN version 0.85.0 (64bit id space)

ich weiss nicht genau, ab wann osm2pgsql 64-bittig ist. könnte sein, daß das daran liegt.

Gruss
walter

Nein, das ist es leider nicht. Meins war schon seit 0.81 64bittig

>osm2pgsql --version
osm2pgsql SVN version 0.84.0 (64bit id space)

Ich vermute ja ein Problem beim Parsen der Relation. Leider kann ich nicht genau nachvollziehen, welche Relation das Problem ist, da die wohl durchgezählt werden und die 741130 keine RelationsID ist. Zumindest gibt es die Relation mit der ID auch gar nicht (mehr).

Hallo frabron,

beobachte mal die osm-dev Mailingliste [1], das gibt es aktuell die selbe Problematik inkl. der Id, die Du angegeben hast.

viele Grüße

Dietmar

[1] https://lists.openstreetmap.org/pipermail/dev/2014-March/027774.html

Einen neuen Planeten runterladen, falls du nicht genau diesen einsetzt, und das Ganze nochmal versuchen. Entweder bleibt die Nummer, sie “wandert” oder das Problem ist weg.

sorry, sonst kann ich nix entdecken. 8 Cores und 12GB mem sind ok?

könntest das pbf ja mal mit osmosis oder osmconvert entpacken - nur um zu sehen, ob es sauber ist.

Gruss
walter

Ja, der Rechner hat 32GB und 2 CPU mit jeweils 8 Kernen. Das Entpacken werde ich mal probieren, obwohl, wenn der Dump da Fehler hätte, müsste das doch schon irgendwo gepostet worden sein, oder?

eigentlich schon. ich hatte aber auch schon mal Übertragungsfehler weil ein paar Bits umgekippt waren.

Hallo Ihr Zwei,

ist mein Beitrag weiter oben nicht zielführend?

viele Grüße

Dietmar

Ups, sorry, hab deinen Beitrag irgendwie übersehen. Das ist aber mein Beitrag in der osm-dev … leider habe ich da (noch) keine Antwort bekommen.