[SERVER-65686] Figure out dependencies between query_sbe and query_sbe_storage libs needed for stats collection Created: 14/Apr/22 Updated: 29/Oct/23 Resolved: 19/Apr/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.0.0-rc1, 6.1.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Irina Yatsenko (Inactive) | Assignee: | Irina Yatsenko (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Backport Requested: |
v6.0
|
||||||||
| Sprint: | QE 2022-04-18, QE 2022-05-02 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 80 | ||||||||
| Description |
|
Originated from BF-24901. The same linker failure can be reproduced on non-UBSAN build variants if use dynamic_cast<IndexScanStage*> in stage_visitors.h. The working theory is that UBSAN somehow substitutes static_cast<IndexScanStage*> with a dynamic_cast (for safety), but the latter needs vtable info of IndexScanStage, which isn't available to the linker because ix_scan.cpp is linked into query_sbe_storage lib but hash_lookup.cpp and loop_join.cpp link into query_sbe. The problem is that query_sbe_storage already depends on query_sbe lib so the above creates a circular dependency. |
| Comments |
| Comment by Githook User [ 19/Apr/22 ] |
|
Author: {'name': 'Irina Yatsenko', 'email': 'irina.yatsenko@mongodb.com', 'username': 'IrinaYatsenko'}Message: (cherry picked from commit 5689f05f30f299560fad5e9eacadc19c54947c91) |
| Comment by Githook User [ 18/Apr/22 ] |
|
Author: {'name': 'Irina Yatsenko', 'email': 'irina.yatsenko@mongodb.com', 'username': 'IrinaYatsenko'}Message: |
| Comment by Irina Yatsenko (Inactive) [ 18/Apr/22 ] |
|
The change that introduced the BF is included in 6.0 so this fix is necessary there as well. |
| Comment by Irina Yatsenko (Inactive) [ 15/Apr/22 ] |
|
The commit that introduced the problem has another place where it circumvents the current dependencies graph with inlining a method. While I agree that UBSAN adding dependencies is unfortunate, I think in this particular case the right fix is to split one of the components to break the cycle the new code created (even if it managed to hide the dependency in non-UBSAN builds). |
| Comment by Andrew Morrow (Inactive) [ 15/Apr/22 ] |
|
You may find some relevant background in |