[SERVER-4233] corruption during '$set' operation Created: 09/Nov/11  Updated: 11/Jul/16  Resolved: 16/Dec/11

Status: Closed
Project: Core Server
Component/s: Write Ops
Affects Version/s: 1.8.4
Fix Version/s: 1.8.5

Type: Bug Priority: Blocker - P1
Reporter: Dominik Gehl Assignee: Aaron Staple
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Attachments: File bug.js    
Operating System: ALL
Participants:

 Description   

Let's assume we have the following record

> db.users.findOne()
{
	"_id" : ObjectId("4e2f0a99a26037e417000056"),
	"info" : {
		"Qu" : {
			"start" : "1320021626",
			"stop" : 1320779121
		},
		"Se" : {
			"start" : 1320021628,
			"stop" : 1320779121
		},
		"Se I" : {
			"start" : "1320021629",
			"stop" : 1320779121
		},
		"Se I_Se M" : {
			"start" : "1320021635",
			"stop" : 1320779121
		},
		"Se M" : {
			"start" : "1320021639",
			"stop" : 1320779121
		},
		"So" : {
			"start" : "1320021641",
			"stop" : 1320779121
		}
	}
}

and update it with the following code

> db.users.update({'_id':ObjectId('4e2f0a99a26037e417000056')},{'$set':{'info.Qu.start':'a', 'info.Se.start':'a', 'info.Se I.start':'a', 'info.Se I_Se M.start' : 'a', 'info.Se M.start':'a', 'info.So.start':'a'}})

Everything seems to work out ok, but info.Se actually was not updated but duplicated !

> db.users.findOne()
{
	"_id" : ObjectId("4e2f0a99a26037e417000056"),
	"info" : {
		"Qu" : {
			"start" : "a",
			"stop" : 1320779121
		},
		"Se" : {
			"start" : 1320021628,
			"stop" : 1320779121
		},
		"Se I" : {
			"start" : "a",
			"stop" : 1320779121
		},
		"Se I_Se M" : {
			"start" : "a",
			"stop" : 1320779121
		},
		"Se M" : {
			"start" : "a",
			"stop" : 1320779121
		},
		"Se" : {
			"start" : 1320021628,
			"stop" : 1320779121
		},
		"So" : {
			"start" : "a",
			"stop" : 1320779121
		}
	}
}
> db.users.findOne({},{'info.Se':1})
{
	"_id" : ObjectId("4e2f0a99a26037e417000056"),
	"info" : {
		"Se" : {
			"start" : 1320021628,
			"stop" : 1320779121
		},
		"Se" : {
			"start" : 1320021628,
			"stop" : 1320779121
		}
	}
}
 



 Comments   
Comment by Eliot Horowitz (Inactive) [ 13/Nov/11 ]

Going to try to get it in for 1.8.5

Comment by Dominik Gehl [ 12/Nov/11 ]

Will this be fixed for the 1.8 branch ?

Comment by Eliot Horowitz (Inactive) [ 12/Nov/11 ]

Traced it back to this fix: SERVER-3370

Comment by Dominik Gehl [ 11/Nov/11 ]

Interesting that the bug is not present on Windows ... I did my tests on Linux 64bit (Ubuntu 11.04)

Comment by galam yum [ 11/Nov/11 ]

hi... I just ran the test with 1.8.4 & pymongo 2.0.01 on windows 7 64 bit.

it worked fine...no duplication.

Comment by Dominik Gehl [ 11/Nov/11 ]

test with fails on 1.8.4, but works in 2.0.1

Comment by Eliot Horowitz (Inactive) [ 11/Nov/11 ]

A test case in the form of one of our javascript cases would be best.
Then we can easily bisect to make sure its fixed and has a test.
And we can also include this explicit case in the regression system.

See:
https://github.com/mongodb/mongo/blob/master/jstests/set1.js

Comment by Dominik Gehl [ 11/Nov/11 ]

Yes, everything above is when running it under 1.8.
2.0 seems to be working ok.

I'm worried about this kind of bug for 2 reasons:

  • it obviously breaks things in 1.8
  • even though it doesn't show up in 2.0, as long as we don't know where the bug comes from in 1.8, it doesn't seem clear if it really is already fixed in 2.0 (i.e. it might just manifest slightly differently in 2.0)

Could you give me explicit specs for the 'test case' you mention (i.e. how would it be different from the mongo shell interaction I put into the initial ticket submission) ?

Comment by Eliot Horowitz (Inactive) [ 11/Nov/11 ]

If you provide a test case, would be easy to see where it started working precisely.

Comment by Eliot Horowitz (Inactive) [ 11/Nov/11 ]

That's all with 1.8?
with 2.0 its working properly?

Comment by Dominik Gehl [ 09/Nov/11 ]

What's happening in the PHP driver seems to be consistent with what I get when I use mongoexport

{ "_id" : { "$oid" : "4e2f0a99a26037e417000056" }, "info" : { "Qu" : { "start" : "a", "stop" : 1320779121 }, "Se" : { "start" : 1320021628, "stop" : 1320779121 }, "Se I" : { "start" : "a", "stop" : 1320779121 }, "Se I_Se M" : { "start" : "a", "stop" : 1320779121 }, "Se M" : { "start" : "a", "stop" : 1320779121 }, "Se" : { "start" : "a" }, "So" : { "start" : "a", "stop" : 1320779121 } } }

So apparently, the second info.Se in the document has only a 'start' property, but no 'stop' property. Inside PHP this second info.Se overwrites the first one.

But, this is then inconsistent with the mongo shell which shows twice an identical info.Se

Comment by Dominik Gehl [ 09/Nov/11 ]

Another remark: if I try to read the data back using the PHP driver, I don't even get the same data as in the mongo shell

 
array(2) {
  ["_id"]=>
  object(MongoId)#6 (1) {
    ["$id"]=>
    string(24) "4e2f0a99a26037e417000056"
  }
  ["info"]=>
  array(6) {
    ["Qu"]=>
    array(2) {
      ["start"]=>
      string(3) "abc"
      ["stop"]=>
      int(1320779121)
    }
    ["Se"]=>
    array(1) {
      ["start"]=>
      string(3) "abc"
    }
    ["Se I"]=>
    array(2) {
      ["start"]=>
      string(3) "abc"
      ["stop"]=>
      int(1320779121)
    }
    ["Se I_Se M"]=>
    array(2) {
      ["start"]=>
      string(3) "abc"
      ["stop"]=>
      int(1320779121)
    }
    ["Se M"]=>
    array(2) {
      ["start"]=>
      string(3) "abc"
      ["stop"]=>
      int(1320779121)
    }
    ["So"]=>
    array(2) {
      ["start"]=>
      string(3) "abc"
      ["stop"]=>
      int(1320779121)
    }
  }
}

info.Se is there (once - not really surprising since PHP will allow only once a given key), but the stop property has disappeared !

Comment by Dominik Gehl [ 09/Nov/11 ]

Hmmm... I've read SERVER-3218, and I really want to believe you that this is the same bug, but it looks kind of different:

  • in SERVER-3218, the issue seems to be related to '0's in the keys. In my case, there are no numbers in the keys
  • in SERVER-3218, the update is executed (even though the wrong key is updated), but here, the value is not updated AND a given key appears twice in the output
Comment by Eliot Horowitz (Inactive) [ 09/Nov/11 ]

This is a manifestation of SERVER-3218.
Will see if we can get in 1.8.5

Comment by Dominik Gehl [ 09/Nov/11 ]

The issue doesn't seem to be present in 2.0.1

Generated at Thu Feb 08 03:05:22 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.