[SERVER-70130] LockerImpl::endWriteUnitOfWork dereferences dangling reference Created: 30/Sep/22 Updated: 05/Dec/22 Resolved: 28/Oct/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jordi Serra Torrens | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Storage Execution
|
| Operating System: | ALL |
| Participants: |
| Description |
|
When 'unlockPending' reaches 1, this unlock call will free the slot, so then the next check on 'it->unlockPending > 0' will access a slot that's free to be reused. |
| Comments |
| Comment by Kaloian Manassiev [ 17/Oct/22 ] |
|
It is not about that the iterator will be reused. It is more like that the slot to which this iterator points is technically "freed". This happens to work fine because we don't actually free the memory so the contents of that PODS are still valid, but it is just a bad programming practice. More in this thread. |
| Comment by Matthew Saltz (Inactive) [ 04/Oct/22 ] |
|
I think this might not actually be a bug, because LockerImpl use is single-threaded. So it's not possible for the iterator to actually be reused until endWriteUnitOfWork returns |