[SERVER-74983] Divergence in sin/cos functions across platforms can result in different 2dsphere index keys for Geo Points Created: 17/Mar/23  Updated: 02/Nov/23  Resolved: 17/May/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Dan Larkin-York Assignee: Mihai Andrei
Resolution: Won't Fix Votes: 0
Labels: index-corruption
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-75392 Update rounding functions in S2 geome... Closed
Duplicate
is duplicated by SERVER-79226 Accuracy differences in geoNear aggre... Closed
Related
Assigned Teams:
Storage Execution
Operating System: ALL
Sprint: QE 2023-05-15, QE 2023-05-29
Participants:

 Description   

When generating a 2dsphere index key for a GeoJSON point, one of the first steps is to convert the lat/long coordinates of said point to a 3D point using the sine and cosine functions. The implementation of these functions can differ slightly across the various platforms that MongoDB can run on, which means that we can wind up with slightly different 3D points across platforms. In practice, this doesn't result in different S2 cell ids (i.e. different 2d sphere index keys), however, in some rare cases when the original point is near an S2Cell boundary, these different implementations can produce 3D points that fall on either side of the boundary and produce different index keys.



 Comments   
Comment by Mihai Andrei [ 17/May/23 ]

This isn't a problem for an individual platform, rather, this is a problem that can potentially manifest when migrating from one platform to another. As such, users with 2dsphere indexes that are migrating between platforms should run the 'validate' command to determine whether any of their 2dsphere indexes are affected by this issue and if so, rebuild/repair any affected indexes.

Comment by Dan Larkin-York [ 14/Apr/23 ]

Re-opening, as we just got some more data that suggests this may not be completely resolved via SERVER-75392.

According to jeff.yemin@mongodb.com, the shell test code pasted above is behaving inconsistently on MacOS depending on a few variables:

  • arm64 hardware
    • 6.0.4 has been failing consistently, at least since mid-March.
    • 4.4.18, 5.0.15 pass when running x86 binaries under emulation.
  • x86 hardware
    • 4.4.18, 5.0.15, 6.04 were passing up until very recently.
    • 4.4.18, 5.0.15, 6.04 are now failing. The only known change was an OS upgrade to 13.3.1. Previous version is uncertain, but believed to be 13.2.

We should first try to reproduce this behavior ourselves, then proceed to investigate the possible causes. I'm particularly suspicious of the fact that the x86 binary behavior changes when run with emulation vs. natively.

Generated at Thu Feb 08 06:29:02 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.