OSRM-extract crashing when ran through command line

james-gould commented 8 years ago

C:\Users\james\Desktop\OSRM\osrm-backend\release>osrm-extract -p profile.lua great-britain-latest.osm.pbf [info] Using script profile.lua [info] Input file: great-britain-latest.osm.pbf [info] Profile: profile.lua [info] Threads: 8 [STXXL-MSG] STXXL v1.4.99 (prerelease/Release) (git 1babe452214b4613a2a488d80073f4185c05a0b3) + gnu parallel(__GLIBCXX__)

is my console output whenever I try and run osrm-extract. It's giving me this error in my Visual Studio debugger:

Unhandled exception at 0x00007FFE7DCA98FE (ucrtbase.dll) in osrm-extract.exe: Fatal program exit requested.

From what I gathered this was an issue with the C++ compiler so I did the following:

Removed all traces of C++ on my system. Uninstalled all redistributables. Visual studio was kept installed.
removed all files and manually set environment variables for stxxl that were created for OSRM.
Created a new directory for OSRM, rebuilt it locally. Decompressed the OSRM_Release and copied over profile.lua, adjusted the .stxxl for pathing and direct=on
copied in my fresh great-britain-latest.osm.pbf file from Geofabrik and ran the command at the top of this post.

When I rebuilt OSRM via build-local.bat I checked to see if it was picking up my C++ compiler correctly, and it detected the correct version and validated it:

CMake suite maintained and supported by Kitware (kitware.com/cmake).
activating VS command prompt ...
platform: X64
cl.exe version
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23918 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption... ]
msbuild version
Microsoft (R) Build Engine version 14.0.25123.0
Copyright (C) Microsoft Corporation. All rights reserved.

Interestingly I just copied over some already extracted wales-latest.osrm data, properties files etc that I was playing with yesterday. I ran osrm-routed with the data, connected to my localhost:5000 and it's working fine. The issue is exclusively with osrm-extract.

daniel-j-h commented 8 years ago

Can you try with a really small extract (e.g. monaco) first to check it's not a bad_alloc / memory issue?

cc @ssuluh @BergWerkGIS

james-gould commented 8 years ago

@daniel-j-h I tried with a small (50mb) extract of Wales and the issue was the same. I thought it may have been an issue with the .stxxl.txt so I removed it (meaning it would default to %appdata% and a 1GB .tmp file) and it was crashing before it even touched the data. EDIT: to clarify, the "crashing" was identical to extracting a larger dataset (800mb, UK.osm.pbf).

No actual errors are returned in the console (bad_alloc etc), it simply crashes with a debug/close windows dialogue after it reaches the bottom line of the console output above.

james-gould commented 8 years ago

debug

There's the debug box that comes up, for context. That's as far as the console gets before it crashes. I've also downloaded a release from build.project-osrm.org and used the latest osrm-extract.exe from there, as well as the entire release folder. Same issue.

And for consistency, here's monaco (didn't realise it was 300kb, thought it was a similar size to Wales. Sorry!)

debug

I took a look in my environment variables to see if it was the .stxxl.txt messing around again, and the local-build.bat had created a new variable. I let the system default be the used .stxxl.txt and it stepped a little further before breaking (note the last line in the console output in comparison to the above ones). I'm not sure if it's significant but I figured I'd post it here just in case:

debug

wilhelmberg commented 8 years ago

Extracting monaco-latest.osm.pbf worked for me (as did great-britain-latest.osm.pbf). I downloaded the OSRM binaries just now from http://build.project-osrm.org/

λ osrm-extract.exe monaco-latest.osm.pbf
[info] Using script profile.lua
[info] Input file: monaco-latest.osm.pbf
[info] Profile: profile.lua
[info] Threads: 16
[STXXL-MSG] STXXL v1.4.99 (prerelease/Release) (git 1babe452214b4613a2a488d80073f4185c05a0b3) + gnu parallel(__GLIBCXX__)
[STXXL-MSG] Disk 'C:\mb\_TEMP\__SUPPORT\__OSRM\stxxl' is allocated, space: 10000 MiB, I/O implementation: wincall queue=0 devid=0
[info] Parsing in progress..
[info] input file generated by Osmium (http://wiki.openstreetmap.org/wiki/Osmium)
[info] timestamp: 2016-08-02T19:29:02Z
[info] Found 3 exceptions to turn restrictions:
[info]   motorcar
[info]   motor_vehicle
[info]   vehicle
[info] Parsing finished after 0.072286 seconds
[info] Raw input contains 18305 nodes, 2552 ways, and 129 relations
[extractor] Sorting used nodes        ... ok, after 0.072181s
[extractor] Erasing duplicate nodes   ... ok, after 0.005139s
[extractor] Sorting all nodes         ... ok, after 0.026685s
[extractor] Building node id map      ... ok, after 0.005688s
[extractor] setting number of nodes   ... ok
[extractor] Confirming/Writing used nodes     ... ok, after 0.000916s
[info] Processed 4265 nodes
[extractor] Sorting edges by start    ... ok, after 0.031273s
[extractor] Setting start coords      ... ok, after 0.006095s
[extractor] Sorting edges by target   ... ok, after 0.022328s
[extractor] Computing edge weights    ... ok, after 0.006578s
[extractor] Sorting edges by renumbered start ... ok, after 0.030025s
[extractor] Writing used edges       ... ok, after 0.000491s
[extractor] setting number of edges   ... ok
[info] Processed 4454 edges
[extractor] Sorting used ways         ... ok, after 0.030902s
[extractor] Sorting 21 restriction. by from... ok, after 0.056513s
[extractor] Fixing restriction starts ... ok, after 0.025714s
[extractor] Sorting restrictions. by to  ... ok, after 0.0418s
[extractor] Fixing restriction ends   ... ok, after 0.01006s
[info] usable restrictions: 19
[extractor] writing street name index ... ok, after 0.000154s
[info] Writing turn lane masks...
[info] done (0.000583)
[info] extraction finished after 0.713683s
[info] Generating edge-expanded graph representation
[info]  - 19 restrictions.
[info] Importing n = 4265 nodes
[info]  - 0 bollard nodes, 4 traffic lights
[info]  and 4454 edges
[info] Graph loaded ok and has 4454 edges
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Node compression ratio: 0.163189
[info] Edge compression ratio: 0.198698
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Generated 4454 nodes in edge-expanded graph
[info] generating edge-expanded edges
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Created 14 entry classes and 427 Bearing Classes
[info] Writing Turn Lane Data to File...
[info] done.
[info] Generated 4454 edge based nodes
[info] Node-based graph contains 1243 edges
[info] Edge-expanded graph ...
[info]   contains 1877 edges
[info]   skips 0 turns, defined by 19 restrictions
[info]   skips 0 U turns
[info]   skips 0 turns over barriers
[info] Timing statistics for edge-expanded graph:
[info] Renumbering edges: 7.6e-05s
[info] Generating nodes: 0.012369s
[info] Generating edges: 0.079855s
[info] Writing Intersection Classification Data
[info] ok, after 0.000257s for 4265 Indices into 427 bearing classes and 14 entry classes and 1207 bearing values.

[info] Saving edge-based node weights to file.
[info] Done writing. (0.000962)
[info] Computing strictly connected components ...
[info] large component [30]=1143
[info] SCC run took: 0.0035649s
[info] Building r-tree ...
[info] constructing r-tree of 4454 edge elements build on-top of 4265 coordinates
[info] finished r-tree construction in 0.002431 seconds
[info] Writing node map ...
[info] [extractor] Writing edge-based-graph edges       ...
[info] ok, after 0.000324s

[info] Processed 1877 edges
[info] Expansion  : 24543.2 nodes/sec and 7152.93 edges/sec
[info] To prepare the data for routing, run: ./osrm-contract monaco-latest.osrm

Things I changed:

copied car.lua -> profile.lua
changed contents of .stxxl.txt to a valid directory

Sorry, but I don't have anything to recommend except the usual suspects:

make sure you got the Visual Studio 2015 Update 3 C++ redistributables installed. VS2015 Update 3 is used to build the binaries
make sure there is enough free HD
make sure you have enough free RAM
make sure you have enough swap
make sure .stxxl.txt points to a valid directory

ssuluh commented 8 years ago

+1 with @BergWerkGIS. I tested latest binary with latest Monaco and no error. Maybe try the official binary build just to eliminate possibility of your build environment. If you still can't run official binary, then it has to be your run time environment.

PS: Update wiki page for Windows compilation to refer to Update 3.

james-gould commented 8 years ago

Thanks guys, I'll run through everything in the morning (heading home from work soon). I'll report back with the problem and how it was solved.

james-gould commented 8 years ago

Ran the extraction on a virtual machine using a freshly installed compiler and built binaries and it worked fine. Something must have gone astray with my compiler and that's been causing the issue. Thanks for the help @daniel-j-h @BergWerkGIS @ssuluh

james-gould commented 8 years ago

@daniel-j-h @ssuluh @BergWerkGIS Reopening because the issue has come back. I reran the builder on a co-worker's machine with the latest compiler (installed right before I tried to extract) and it crashed at the same point.

Back on my machine I removed the .stxxl from the osrm-backend directory, tried it within the release directory and both crashed my extracter again. I then completely removed it from any working directory and the crash stopped, turning into a memory_alloc problem (which I understand).

I can extract small (< 100mb) .osm.pbf files because the temp file set by the default .stxxl supports them, but if I want to extract the UK (870mb as of the 4th August) it will give me a bad_alloc error.

could one of you provide some documentation on where to store the .stxxl and some adequate settings to use? I've been fiddling with this for a few days and can't figure it out.

Also, would an environment variable be needed for the .stxxl.txt file? Currently I have mine pointed to te backend file but I'm not sure if I should just remove it completely.

daniel-j-h commented 8 years ago

I think these are the docs you need: http://stxxl.sourceforge.net/tags/master/install_config.html

ssuluh commented 8 years ago

James, I retest your scenario with great-britain-latest and I extract it multiple times and I couldn't repro your crash.

My environment:

Windows 10, all latest update. Plenty of disk space in c:\temp (which is where the .stxxl.txt points to). I have 16gig of RAM in my pc.
Visual Studio 2015 Update 3 C++ redistributables.
Official latest windows release build of osrm from http://build.project-osrm.org/. At the time of my test it shows: Release build (August 04 2016 14:56:22 CEST)

Steps:

Extract everything from the zip file into clean folder.
I don't modify anything and leave .stxxl.txt file alone. But just make sure I have c:\temp folder.
No extra step to define any env vars or including that folder from step (1) in your PATH.
Open command line cd to wherever you extract the binary to from step (1).
Run extract: osrm-extract.exe -p car.lua d:\workspace\osrm-data\great-britain-latest.osm.pbf. (I have all my osm data in that d:\workspace\osrm-data folder, so point that to wherever your pbf file is).

Since you mention 'latest compiler' in your earlier post, are you running your own build or are you running the official build ? If you're running your own build, please confirm it first with official build just so we can at least rule out compiling/building issues.

james-gould commented 8 years ago

@ssuluh thank you, apparently I needed to explicitly state osrm-extract.exe rather than just osrm-extract, not entirely sure why that would be.

Project-OSRM / osrm-backend

OSRM-extract crashing when ran through command line #2735