I think this is a bug but I'm still ramping up on the codebase.
Step to reproduce:
1) Load a data set into memory on a box with constraints that will load the first time but fail the second time (https://github.com/Project-OSRM/osrm-backend/issues/5408) For example, load an 6GB Data Set on a box with 8GB of memory. It will load fine the first time but will most likely fail the second time.
Running this the first time will succesfuly load the data set into memory:
osrm-datastore --dataset-name=car osm.osrm
[info] Data layout has a size of 1745 bytes
[info] Allocating shared memory of 6024689030 bytes
[info] Data layout has a size of 1283 bytes
[info] Allocating shared memory of 17329549147 bytes
[info] All data loaded. Notify all client about new data in:
[info] car/static 0
[info] car/updatable 1
[info] All clients switched.
3) Attempt to load the data set in to memory again. It will fail with the following error.
osrm-datastore --dataset-name=car osm.osrm
[info] Data layout has a size of 1745 bytes
[info] Allocating shared memory of 6024689030 bytes
[info] Data layout has a size of 1283 bytes
[info] Allocating shared memory of 17329549147 bytes
[error] Error while attempting to allocate shared memory: Cannot allocate memory, code 13
terminate called after throwing an instance of 'osrm::util::exception'
what(): Cannot allocate memoryinclude/storage/shared_memory.hpp:311
4) osrm-datastore --list shows nothing...
osrm-datastore --list
[info] name shm key timestamp size
5) Attempt to load data set again, shows warnings about existing regions
[warn] Old shared memory region 0 still exists.
[info] Retrying removal...
[info] ok.
[info] Data layout has a size of 1745 bytes
[info] Allocating shared memory of 6024689030 bytes
[warn] Old shared memory region 1 still exists.
[info] Retrying removal...
[info] ok.
[info] Data layout has a size of 1283 bytes
[info] Allocating shared memory of 17329549147 bytes
[error] Error while attempting to allocate shared memory: Cannot allocate memory, code 13
terminate called after throwing an instance of 'osrm::util::exception'
what(): Cannot allocate memoryinclude/storage/shared_memory.hpp:311
but --list still shows nothing
osrm-datastore --list
[info] name shm key timestamp size
From what I can tell, the shared memory still exists and is being used by existing osrm processess. --remove-locks and --spring-clean appear to do nothing as well and attemping to run osrm-datastore after either results in the same code 13 error.
I think this is a bug but I'm still ramping up on the codebase.
Step to reproduce: 1) Load a data set into memory on a box with constraints that will load the first time but fail the second time (https://github.com/Project-OSRM/osrm-backend/issues/5408) For example, load an 6GB Data Set on a box with 8GB of memory. It will load fine the first time but will most likely fail the second time.
Running this the first time will succesfuly load the data set into memory:
2) Confirm data set is in memory
3) Attempt to load the data set in to memory again. It will fail with the following error.
4)
osrm-datastore --list
shows nothing...5) Attempt to load data set again, shows warnings about existing regions
but --list still shows nothing
From what I can tell, the shared memory still exists and is being used by existing osrm processess.
--remove-locks
and--spring-clean
appear to do nothing as well and attemping to runosrm-datastore
after either results in the same code 13 error.