Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-24054

JS segmentation fault on load of certain nans

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 3.2.1
    • Fix Version/s: 3.2.7, 3.3.6
    • Component/s: Querying, Shell
    • Labels:
    • Environment:
      Ubuntu 14.04.3 LTS
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Completed:
    • Sprint:
      Platforms 14 (05/13/16)

      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.

      1. activities.bson
        1 kB
        Patrick Woo
      2. activities.metadata.json
        0.5 kB
        Patrick Woo
      3. log.txt
        14 kB
        Patrick Woo

        Activity

        Hide
        patrick.woo@gmail.com Patrick Woo added a comment -

        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.

        Show
        patrick.woo@gmail.com Patrick Woo added a comment - 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.
        Hide
        jason.carey Jason Carey added a comment -

        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:

        mongodump -d DATABASE -c COLLECTION -q '{_id: ID}'  
        

        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,
        Jason

        Show
        jason.carey Jason Carey added a comment - 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: mongodump -d DATABASE -c COLLECTION -q '{_id: ID}' 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, Jason
        Hide
        patrick.woo@gmail.com Patrick Woo added a comment -

        Hi Jason,

        I've attached the first activity the shell crashes on.

        Patrick

        Show
        patrick.woo@gmail.com Patrick Woo added a comment - Hi Jason, I've attached the first activity the shell crashes on. Patrick
        Hide
        jason.carey Jason Carey added a comment -

        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,
        Jason

        Show
        jason.carey Jason Carey added a comment - 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, Jason
        Hide
        patrick.woo@gmail.com Patrick Woo added a comment -

        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,
        Patrick

        Show
        patrick.woo@gmail.com Patrick Woo added a comment - 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, Patrick
        Hide
        jason.carey Jason Carey added a comment -

        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,
        Jason

        Show
        jason.carey Jason Carey added a comment - 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, Jason
        Hide
        patrick.woo@gmail.com Patrick Woo added a comment -

        Thanks for all the help .

        Regards,
        Patrick

        Show
        patrick.woo@gmail.com Patrick Woo added a comment - Thanks for all the help . Regards, Patrick
        Hide
        xgen-internal-githook Githook User added a comment -

        Author:

        {u'username': u'hanumantmk', u'name': u'Jason Carey', u'email': u'jcarey@argv.me'}

        Message: SERVER-24054 JS segfault on load of certain nans
        Branch: master
        https://github.com/mongodb/mongo/commit/35443b806c8050416e76040e0604da8c9acd3c74

        Show
        xgen-internal-githook Githook User added a comment - Author: {u'username': u'hanumantmk', u'name': u'Jason Carey', u'email': u'jcarey@argv.me'} Message: SERVER-24054 JS segfault on load of certain nans Branch: master https://github.com/mongodb/mongo/commit/35443b806c8050416e76040e0604da8c9acd3c74
        Hide
        xgen-internal-githook Githook User added a comment -

        Author:

        {u'username': u'hanumantmk', u'name': u'Jason Carey', u'email': u'jcarey@argv.me'}

        Message: SERVER-24054 JS segfault on load of certain nans

        (cherry picked from commit 35443b806c8050416e76040e0604da8c9acd3c74)
        Branch: v3.2
        https://github.com/mongodb/mongo/commit/a91418624c39229ba16d24b3cf988d2f9b2d73f3

        Show
        xgen-internal-githook Githook User added a comment - Author: {u'username': u'hanumantmk', u'name': u'Jason Carey', u'email': u'jcarey@argv.me'} Message: SERVER-24054 JS segfault on load of certain nans (cherry picked from commit 35443b806c8050416e76040e0604da8c9acd3c74) Branch: v3.2 https://github.com/mongodb/mongo/commit/a91418624c39229ba16d24b3cf988d2f9b2d73f3

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

                Agile