[SERVER-35964] Delete UBSan concurrency_replication* tasks Created: 05/Jul/18 Updated: 01/Jan/24 Resolved: 21/Dec/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | 4.1.1 |
| Fix Version/s: | 7.3.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Robert Guo (Inactive) | Assignee: | Mikhail Shchatko |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | open_todo_in_code, tig-concurrency | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Correctness
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Backport Requested: |
v4.0, v3.6
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Linked BF Score: | 30 | ||||||||||||||||
| Description |
|
concurrency_replication* suites have high memory usage on UBSan, so we run them differently for now while the underlying cause is still being investigated |
| Comments |
| Comment by Githook User [ 21/Dec/23 ] |
|
Author: {'name': 'Mikhail Shchatko', 'email': 'mikhail.shchatko@mongodb.com', 'username': 'MikhailShchatko'}Message: GitOrigin-RevId: 39fb7ee8fb6ecb7e5a6d6252a41c5d3a410477f1 |
| Comment by Steven Vannelli [ 10/May/22 ] |
|
Moving this ticket to the Backlog and removing the "Backlog" fixVersion as per our latest policy for using fixVersions. |
| Comment by Max Hirschhorn [ 25/Feb/19 ] |
daniel.gottlieb, I think we can see whether the behavior is also observed when using --sanitize=undefined --allocator=tcmalloc, and if so, then set heapProfilingEnable=1 to see where the allocations are come from that don't appear to released until the process exits. |
| Comment by Daniel Gottlieb (Inactive) [ 25/Feb/19 ] |
|
max.hirschhorn is the relation we've seen between the system allocator and memory usage sufficient to say we've "understood" the cause? If so, |
| Comment by Max Hirschhorn [ 31/Oct/18 ] |
april.schoffer, we need to figure out the root cause behind the memory pressure when running with UBSan (undefined behavior sanitizer) enabled. The work that has been done on this ticket was to stop the bleeding in the linked BF ticket, but we need to understand the actual problem in order to revert those changes. |
| Comment by April Schoffer [ 31/Oct/18 ] |
|
Does this ticket still need to be in investigating status? What do we need to figure out to schedule it? |
| Comment by Max Hirschhorn [ 06/Sep/18 ] |
No - I wasn't sure if it would give a clue as to where the memory pressure is coming from. |
| Comment by Robert Guo (Inactive) [ 06/Sep/18 ] |
|
max.hirschhorn Nope, that was an oversight as the simultaneous suite didn't fail in the BF ticket. Do you want to file a separate ticket for blacklisting that suite? |
| Comment by Max Hirschhorn [ 06/Sep/18 ] |
|
robert.guo, I forget - did you already look into why the concurrency_simultaneous_replication task doesn't have this issue on the UBSan builder? |
| Comment by Max Hirschhorn [ 05/Sep/18 ] |
|
The concurrency_replication_multi_stmt_txn_ubsan.yml test suite introduced by the changes from 806b9c3 as part of |
| Comment by Max Hirschhorn [ 11/Jul/18 ] |
|
Bumping this out far into the future. It's something we should definitely continue to look into but isn't the most pressing thing now that the UBSan builder has returned to being green. |
| Comment by Githook User [ 06/Jul/18 ] |
|
Author: {'username': 'guoyr', 'name': 'Robert Guo', 'email': 'robert.guo@10gen.com'}Message: (cherry picked from commit a6e2c10af2dcfa862c6afa0fb1504a5d2b092d09) |
| Comment by Githook User [ 05/Jul/18 ] |
|
Author: {'username': 'guoyr', 'name': 'Robert Guo', 'email': 'robert.guo@10gen.com'}Message: |