[SERVER-24054] JS segmentation fault on load of certain nans Created: 04/May/16 Updated: 08/Jan/24 Resolved: 10/May/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying, Shell |
| Affects Version/s: | 3.2.1 |
| Fix Version/s: | 3.2.7, 3.3.6 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Patrick Woo | Assignee: | Mira Carey |
| Resolution: | Done | Votes: | 0 |
| Labels: | code-and-test | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Ubuntu 14.04.3 LTS |
||
| Attachments: |
|
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Backport Completed: | |
| Sprint: | Platforms 14 (05/13/16) |
| Participants: |
| Description |
|
Querying for a set of documents always produces a segfault on our system when including a specific document field that may or may not contain corrupted data. The fault is included in the logs. Executing a db.collection.find() with the field excluded as a projection does not produce this crash. |
| Comments |
| Comment by Githook User [ 18/May/16 ] | |
|
Author: {u'username': u'hanumantmk', u'name': u'Jason Carey', u'email': u'jcarey@argv.me'}Message: (cherry picked from commit 35443b806c8050416e76040e0604da8c9acd3c74) | |
| Comment by Githook User [ 10/May/16 ] | |
|
Author: {u'username': u'hanumantmk', u'name': u'Jason Carey', u'email': u'jcarey@argv.me'}Message: | |
| Comment by Patrick Woo [ 06/May/16 ] | |
|
Thanks for all the help Regards, | |
| Comment by Mira Carey [ 06/May/16 ] | |
|
Patrick, We take any crash seriously. I just wanted to confirm with you that your use case wouldn't be hurt if we just convert nan's from bson into the javascript nan. This has the slight downside that documents with novel nan's won't round trip if the nan fields are loaded into js. Glad to hear you have a workaround in the meanwhile, | |
| Comment by Patrick Woo [ 06/May/16 ] | |
|
Hi Jason, We have zero need for this. The only expectation was that the shell would not crash under this circumstance and allow us to write over this value with "valid" numerical data. It does appear as if the legacy php mongo plugin allows us to do just that, so it is no longer a pressing issue on our end. Thanks, | |
| Comment by Mira Carey [ 06/May/16 ] | |
|
Patrick, After a little looking, it appears that the value the shell is crashing on is a negative nan (specifically -nan(0xffffffffe7961)). The shell is crashing because SpiderMonkey makes aggressive use of the nan space in iee754 doubles to store things other than nans, which is reasonable because javascript only has 1 kind of nan. Do you have a need for roundtrip-ability of different kinds of nan's through the shell? Regards, | |
| Comment by Patrick Woo [ 05/May/16 ] | |
|
Hi Jason, I've attached the first activity the shell crashes on. Patrick | |
| Comment by Mira Carey [ 05/May/16 ] | |
|
Patrick, I can see a couple of avenue's by which corrupt bson might be able to crash the shell, but in order to be sure, would it be possible for you to provide a binary dump of the documents in question? If you can project the non-corrupt part of the document that's crashing the shell, and if that part includes the id, you might do so using mongodump as follows:
where the various all caps values are respectively the database, collection and id of the document that's causing you problems. If you could attach the dump that produces, that would be enough to see exactly the kind of document corruption you're seeing. Regards, | |
| Comment by Patrick Woo [ 04/May/16 ] | |
|
I've also written a short script to identify which documents trigger the segfault. It looks something like this: db.collection.find().forEach(function(document) { print(document.id); document.field; }); The mere act of accessing document.field is enough to trigger the segfault. Removing the line will complete the loop without issues. |