-
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
assertion failed @ QueryHeap::MinKey() #5843
Comments
Query without |
I expect this will be symmetric and the assertion can fail for Do still have the query that causes the failure? Would be good to reduce it down to a test case. |
@mjjbell here's the failing instance If you run the docker image, it'll sigfault. |
I've minimized the test case even further. https://github.com/slavanap/osrm-5843 |
Thanks for the details. Here's what I've understood so far. Similar to #5840, this is due to a potential mismatch between what request coordinates can be snapped to in the network, and what is valid after a traffic update. This line of
It updates the last segment in the way the source coordinates are snapped to After the traffic update, that segment is therefore marked as invalid. Given this is a one-way road, no route can be found from the source. As you've seen, it looks like the alternative path code always assumes the source/target phantom nodes are valid and the search heaps are populated. Interestingly, flipping the source/target coordinates doesn't fail the assertion. If you make the middle segment zero speed and rate instead, the reverse route will also fail:
This is a long-winded way of saying that yes, both heap assertions can fail for the same reason. Ultimately, adding this check won't help in finding a route though. I think the longer-term approach suggested in #5840 of snapping to N nearest locations to find a valid route would also be needed here. |
Will setting edge value to something very small resolve the "snapping" issue? like to 0.00000001 |
It should prevent it being marked as invalid. I can't say if it has other side effects though. I think you'll just end up with more expensive routes (including alternatives) from that source. |
I see. Is there any way to completely remove that edge and rebuild the graph (even if it'd take long, I'm running offline analysis anyway)? I'm thinking of altering OSM file. Probably it'd work. Or maybe there's other command with OSRM? |
If you're ok with reconstructing the graph, you could probably utilise the lua profile scripting and a combination of process_way for removing edges and process_segment to set speed/rate from your CSV file. Then you won't have to edit the OSM file. |
This is solved for me. Thank you! @mjjbell, will adding checks be enough for |
Let's also add a testcase for this. I'm happy to make the PR. |
If you can make a PR soon, I've actually got some time to do a proper release - I've tagged 5.23.0-rc.1 already, but it'd be nice to get this fix in as well. |
Created #5851 |
I've localized the issue and made the proper patch (below). The assetion only fails with
alternatives=true
in the query.I'm not aware of the algorithm, thus this patch may be not exhaustive.
backtrace:
The text was updated successfully, but these errors were encountered: