[SERVER-2009] potentially incorrectly handled test in client cursor may result in improper skipping Created: 26/Oct/10 Updated: 12/Jul/16 Resolved: 03/Jun/11 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 1.9.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Aaron Staple | Assignee: | Aaron Staple |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Participants: |
| Description |
|
I haven't confirmed this behavior with a test, but it looks like the following sequence of events may be possible: 1) a client cursor points to a btree entry with key 'a' with disk loc X and is yielding or awaiting getMore As part of 3), clientcursor's aboutToDelete() will expect to find a cursor pointing at btree node <'a',X> and call checkLocation() on that cursor. Because the btree key has been removed, checkLocation() will advance to the next key past the expected one. If this key has a refLoc other than X (which is quite likely), aboutToDelete() will log a warning and advance the cursor again anyway, even though it should not advance because the btree key is pointing at a different record location. |
| Comments |
| Comment by auto [ 02/Jun/11 ] |
|
Author: {u'login': u'astaple', u'name': u'Aaron', u'email': u'aaron@10gen.com'}Message: |
| Comment by auto [ 25/Mar/11 ] |
|
Author: {u'login': u'astaple', u'name': u'Aaron', u'email': u'aaron@10gen.com'}Message: |
| Comment by auto [ 25/Mar/11 ] |
|
Author: {u'login': u'astaple', u'name': u'Aaron', u'email': u'aaron@10gen.com'}Message: |