-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
osrm-partition assert (crash) with planet-data on bicycle profile #6122
Comments
Take a look at #6121, we're currently debugging the same issue. |
As a temporary workaround, I would suggest switching to the CH algorithm for profiles you don't need to customize - bike/walk are good candidates. This means you would use |
No success with osrm-contract: $ time osrm-contract bike.osrm real 47m10.948s (gdb) bt |
Hmm, that is interesting. Are you able to run a debug build to get better symbols (and possibly trigger an assertion?) It might take a while.... |
I will try to build debug version of package, soon. Now I have some success with --max-cell-sizes (as workaround from another bug). I'm not sure what this option do and not sure I have full routing data as result. Success run: $ osrm-partition --max-cell-sizes=1024,16384,262144,4194304 bike.osrm [info] Computing recursive bisection |
osrm-customize crashed after previous osrm-partition with max-cell-sizes: $ osrm-partition --max-cell-sizes=1024,16384,262144,4194304 bike.osrm $ time osrm-customize bike.osrm real 23m14.582s (gdb) No useful info in gdb backtrace. Doing debug package build... |
-DCMAKE_BUILD_TYPE=Debug failed to compile (scripting_environment_lua.cpp:450:9: error: ‘this’ pointer is null [-Werror=nonnull] -DCMAKE_BUILD_TYPE=RelWithDebInfo compiled successfully Run osrm-customize after "success" osrm-partition with --max-cell-sized: $ time osrm-customize bike.osrm [info] Loaded edge based graph: 3001997784 edges, 739184293 nodes Aborted (core dumped) real 135m4.916s Unfortunately, there was no free space in current directory to write coredump, but you can see some assertions before crash. Strange but this time osrm-customize run for 2+ hours, compared to 23 minutes previous run. Next I'll try to run osrm-contract, again ... |
Strange things. Version with -DCMAKE_BUILD_TYPE=RelWithDebInfo failed even on osrm-extract. Please explain what to do next ? Maybe try with patch(-es) from #6121 ? $ time osrm-extract -p /usr/share/osrm/profiles/bicycle.lua bike.osm.pbf [info] Parsed 0 location-dependent features with 0 GeoJSON polygons (gdb) bt |
Looks like the With regards to |
Details: $ time osrm-contract bike.osrm real 181m33.688s (gdb) bt |
Applied patches #6123 #6124 and have same assertion and crash: $ time osrm-partition bike.osrm real 855m38.852s (gdb) bt |
This is where the The default max cell sizes are This will need to be addressed in OSRM at some point given OSM data is only getting bigger, but for now this workaround is required if you see that exception message. |
$ osrm-partition --max-cell-sizes=1024,16384,262144,4194304 bike.osrm processed successfully w/o crash but: $ time osrm-customize bike.osrm time osrm-customize bike.osrm real 124m23.947s I have 512GB RAM (~450GB free) plus 116GB SWAP This was RelWithDebInfo, next try with Release build. |
Same problem but instead of 124 minutes, Release build end just after 15 minutes: $ time osrm-customize bike.osrm real 15m31.712s |
Can you list the data directory? |
Now 90GB more swap added and osrm-customize try again. Update: failed even with 90GB swap added $ free -h $ ls -lh |
Have success with patched version. Need:
osrm-extract -p /usr/share/osrm/profiles/bicycle.lua bike.osm.pbf # 255m20.950s Checked Planet-routing (bicycle profile) accross few countries. Everything seems ok. |
Hi!
I'm maintainer of weekly-updated Planet OSRM routing server.
It's used for online routing in several Open Source projects.
It was running more than 1 year w/o any problems.
Cron script run every week:
Hardware: 20-core Xeon, 512Gb RAM (with 32gb swap) and 1.5TB SSD
Used osrm-backend package build from source:
https://aur.archlinux.org/packages/osrm-backend/
Versions with problem 100% exist: 5.23.0 (my previous) and 5.25.0 (fresh)
Case with Problem:
CRASH - osrm-partition on Planet-data with bicycle (and possible foot) profile
Cases without Problem:
OK - profile car (smaller)
OK - older (before ~Aug 20th 2021) Planet successed with all profiles (incl. bicycle and foot)
How to 100% reproduce:
After 5-6 hours it crashed.
Log output:
[info] Computing recursive bisection
[info] Loaded compressed node based graph: 741513480 edges, 1811915677 nodes
[info] running partition: 128 1.2 0.25 10 1000 # max_cell_size balance boundary cuts small_component_size
[info] Found 1530830824 SCC (827 large, 1530829997 small)
[info] SCC run took: 239.517s
[info] Full bisection done in 8751.55s
[info] Loaded node based graph to edge based graph mapping
[info] Loaded edge based graph for mapping partition ids: 3001997784 edges, 739184293 nodes
[info] Fixed 124433827 unconnected nodes
[info] Edge-based-graph annotation:
[info] level 1 #cells 2471974 bit size 22
[info] level 2 #cells 259942 bit size 18
[info] level 3 #cells 16401 bit size 15
[info] level 4 #cells 530 bit size 10
[info] Renumbered data in 3711.91 seconds
terminate called after throwing an instance of 'osrm::util::exception'
what(): Can't pack the partition information at level 4 into a 64bit integer. Would require 65 bits.
Aborted (core dumped)
GDB coredump stack trace:
(gdb) bt
#0 0x00007f0ec53bed22 in raise () from /usr/lib/libc.so.6
#1 0x00007f0ec53a8862 in abort () from /usr/lib/libc.so.6
#2 0x00007f0ec5602802 in __gnu_cxx::__verbose_terminate_handler () at /build/gcc/src/gcc/libstdc++-v3/libsupc++/vterminate.cc:95
#3 0x00007f0ec560ec8a in __cxxabiv1::__terminate (handler=) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:48
#4 0x00007f0ec560ecf7 in std::terminate () at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:58
#5 0x00007f0ec560ef8e in __cxxabiv1::__cxa_throw (obj=, tinfo=0x7f0ec58f82e0 , dest=0x55b31866c400 osrm::util::exception::~exception())
at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_throw.cc:95
#6 0x00007f0ec5860cb4 in ?? () from /usr/lib/libosrm_partition.so
#7 0x00007f0ec588df2c in osrm::partitioner::Partitioner::Run(osrm::partitioner::PartitionerConfig const&) () from /usr/lib/libosrm_partition.so
#8 0x000055b31866a294 in main ()
The text was updated successfully, but these errors were encountered: