Skip to content
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

Fix metric offset overflow for large MLD partitions #6124

Merged
merged 2 commits into from Sep 21, 2021

Conversation

mjjbell
Copy link
Member

@mjjbell mjjbell commented Sep 13, 2021

Issue

As discovered in #6121

Each MLD cell has source and destination nodes. MLD is keeping a |source| x |destination| sized table
for various metrics (distances, durations, etc) from each source to all destinations in a cell.

It stores all of the values for a metric in one large array, with an offset for each cell to find its values. The offset is currently
limited to 32 bit values, which overflows on very large graphs (e.g. Planet OSM).

We fix this by changing the offsets to be uint64_t types.

Tasklist

@mjjbell mjjbell force-pushed the mbell/mld_offset_overflow branch 2 times, most recently from 746c710 to 56da876 Compare September 13, 2021 19:29
using ValueOffset = std::uint32_t;
using BoundaryOffset = std::uint32_t;
using ValueOffset = std::size_t;
using BoundaryOffset = std::size_t;
using BoundarySize = std::uint32_t;
Copy link
Member Author

@mjjbell mjjbell Sep 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OSM contains ~800 million ways, so 32 bit should be safe to use for boundary sizes...for now.

Each MLD cell has source and destination nodes.
MLD is keeping a |source| x |destination| sized table
for various metrics (distances, durations, etc) from each
source to all destinations in a cell.

It stores all of the values for a metric in one large array, with
an offset for each cell to find its values. The offset is currently
limited to 32 bit values, which overflows on very large graphs
(e.g. Planet OSM).

We fix this by changing the offsets to be uint64_t types.
@danpat
Copy link
Member

danpat commented Sep 21, 2021

@mjjbell I think I'm going to make a new release once this is merged - any objections?

@mjjbell
Copy link
Member Author

mjjbell commented Sep 21, 2021

@danpat sounds good 👍

I can see I tested the package publishing from Github Actions in https://github.com/mjjbell/osrm-backend/actions/runs/998677972, but I think I must have removed the generated artifacts to not confuse myself in the future.

@mjjbell mjjbell merged commit f6349a7 into Project-OSRM:master Sep 21, 2021
@mjjbell
Copy link
Member Author

mjjbell commented Sep 21, 2021

Proof that it is indeed a breaking change to the data format: #6128

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants