[SERVER-9605] HexData(0, "000000000000000000000005") will throw Created: 07/May/13 Updated: 11/Jul/16 Resolved: 10/Jun/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | JavaScript |
| Affects Version/s: | 2.4.1 |
| Fix Version/s: | 2.4.5, 2.5.1 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Huy Nguyen | Assignee: | Tad Marshall |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
AWS m2.2xlarge (AMI: ami-8e27adbe) Production Amazon Linux. RAID10 8 drives on provisioned IOPS data partition. logs partition separate from data |
||
| Issue Links: |
|
||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||
| Steps To Reproduce: |
//So then the following should work!
//But it throws... |
||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||
| Description |
|
Our .net client stores a long id of 5. Before saving the id however, we convert it to big endian byte[] of 12 in length (to be the same size of mongo object id) for future proofing. This however should not matter as the following is clearly self explanatory. See "steps to reproduce" I actually use these JS functions as a work-around which allows me to call:
|
| Comments |
| Comment by auto [ 19/Jun/13 ] | ||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'tadmarshall', u'name': u'Tad Marshall', u'email': u'tad@10gen.com'}Message: Do not use hard-coded length of 16 to process variable length hex string. | ||||||||||||||||||||||||||||||||||||
| Comment by Tad Marshall [ 10/Jun/13 ] | ||||||||||||||||||||||||||||||||||||
|
Tests that will be covered by | ||||||||||||||||||||||||||||||||||||
| Comment by Shaun Verch [ 14/May/13 ] | ||||||||||||||||||||||||||||||||||||
|
After | ||||||||||||||||||||||||||||||||||||
| Comment by Tad Marshall [ 07/May/13 ] | ||||||||||||||||||||||||||||||||||||
|
The above commit fixes the bug. Leaving this ticket open until a regression test is written. | ||||||||||||||||||||||||||||||||||||
| Comment by auto [ 07/May/13 ] | ||||||||||||||||||||||||||||||||||||
|
Author: {u'date': u'2013-05-07T11:23:40Z', u'name': u'Tad Marshall', u'email': u'tad@10gen.com'}Message: Do not use hard-coded length of 16 to process variable length hex string. | ||||||||||||||||||||||||||||||||||||
| Comment by Tad Marshall [ 07/May/13 ] | ||||||||||||||||||||||||||||||||||||
|
Hi Huy, Thanks for the report! I reproduced it in the current code. This is a bug in the V8 version of hexToBinData() in src/mongo/scripting/v8_dp.cpp lines 701 to 716:
It is using a hard-coded length of 16 bytes, even though it just calculated the correct length of the string. The SpiderMonkey version doesn't have this problem; src/mongo/scripting/engine_spidermonkey.cpp lines 907 to 926:
Changing the V8 version to use the calculated length fixes the problem. Tad |