[SERVER-19638] Corrupt storage.bson causes segfault Created: 28/Jul/15  Updated: 26/Jun/19  Resolved: 26/Jun/19

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: 3.0.5, 3.1.6
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Robert Guo (Inactive) Assignee: Daniel Solnik (Inactive)
Resolution: Done Votes: 0
Labels: 32qa, execution_intern, neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File storage.bson    
Operating System: ALL
Steps To Reproduce:

1. replace your storage.bson with the one attached
2. start mongod

Sprint: Execution Team 2019-07-01
Participants:

 Description   

Changing the length of a string BSON element in storage.bson to a very large number can cause a segfault. Please see attached storage.bson and stack trace for reference.

stack trace:

➜  dev.mongo git:(master) ✗ lldb -- ./mongod 
(lldb) target create "./mongod"
Current executable set to './mongod' (x86_64).
(lldb) r
Process 24578 launched: './mongod' (x86_64)
Process 24578 stopped
* thread #1: tid = 0x1f7f86, 0x00007fff95ecc135 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 533, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1036ffffd)
    frame #0: 0x00007fff95ecc135 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 533
libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell:
->  0x7fff95ecc135 <+533>: vmovups -0x40(%rsi), %ymm2
    0x7fff95ecc13a <+538>: subq   $0x40, %rsi
    0x7fff95ecc13e <+542>: subq   $0x40, %rdx
    0x7fff95ecc142 <+546>: ja     0x7fff95ecc122            ; <+514>
(lldb) bt
* thread #1: tid = 0x1f7f86, 0x00007fff95ecc135 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 533, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1036ffffd)
  * frame #0: 0x00007fff95ecc135 libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 533
    frame #1: 0x00007fff9d07b225 libc++.1.dylib`std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__init(char const*, unsigned long) + 91
    frame #2: 0x00000001000231eb mongod`mongo::BSONElement::str() const [inlined] std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string(this=<unavailable>, __s=<unavailable>, __n=<unavailable>) + 155 at string:2024
    frame #3: 0x00000001000231e0 mongod`mongo::BSONElement::str() const [inlined] std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string(__s=<unavailable>, __n=<unavailable>) at string:2022
    frame #4: 0x00000001000231e0 mongod`mongo::BSONElement::str(this=<unavailable>) const + 144 at bsonelement.h:359
    frame #5: 0x000000010063e136 mongod`mongo::StorageEngineMetadata::read() [inlined] mongo::BSONElement::String(this=<unavailable>) const + 3734 at bsonelement.h:79
    frame #6: 0x000000010063e116 mongod`mongo::StorageEngineMetadata::read(this=0x0000000103300c40) + 3702 at storage_engine_metadata.cpp:182
    frame #7: 0x000000010063d0a3 mongod`mongo::StorageEngineMetadata::forPath(dbpath=<unavailable>) + 259 at storage_engine_metadata.cpp:70
    frame #8: 0x000000010063ec72 mongod`mongo::StorageEngineMetadata::getStorageEngineForPath(dbpath=0x00007fff5fbfdf68) + 34 at storage_engine_metadata.cpp:82
    frame #9: 0x0000000100599739 mongod`mongo::ServiceContextMongoD::initializeGlobalStorageEngine(this=0x0000000103719b00) + 89 at service_context_d.cpp:81
    frame #10: 0x00000001000018b9 mongod`mongo::_initAndListen(listenPort=<unavailable>) + 377 at db.cpp:414
    frame #11: 0x0000000100001103 mongod`mongo::initAndListen(listenPort=<unavailable>) + 19 at db.cpp:592
    frame #12: 0x000000010000688c mongod`main [inlined] mongoDbMain(int, char**, char**) + 995 at db.cpp:822
    frame #13: 0x00000001000064a9 mongod`main(argc=<unavailable>, argv=<unavailable>, envp=<unavailable>) + 25 at db.cpp:637
    frame #14: 0x00007fff91a4a5ad libdyld.dylib`start + 1
    frame #15: 0x00007fff91a4a5ad libdyld.dylib`start + 1
(lldb) 



 Comments   
Comment by Daniel Solnik (Inactive) [ 26/Jun/19 ]

When trying to reproduce, it seems like this problem has been fixed.

2019-06-26T11:53:21.081-0400 I CONTROL  [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2019-06-26T11:53:21.086-0400 I CONTROL  [initandlisten] MongoDB starting : pid=6903 port=27017 dbpath=/data/db 64-bit host=Daniels-MacBook-Pro-7.local
2019-06-26T11:53:21.086-0400 I CONTROL  [initandlisten] db version v4.0.10
2019-06-26T11:53:21.086-0400 I CONTROL  [initandlisten] git version: c389e7f69f637f7a1ac3cc9fae843b635f20b766
2019-06-26T11:53:21.086-0400 I CONTROL  [initandlisten] allocator: system
2019-06-26T11:53:21.086-0400 I CONTROL  [initandlisten] modules: enterprise 
2019-06-26T11:53:21.086-0400 I CONTROL  [initandlisten] build environment:
2019-06-26T11:53:21.086-0400 I CONTROL  [initandlisten]     distarch: x86_64
2019-06-26T11:53:21.086-0400 I CONTROL  [initandlisten]     target_arch: x86_64
2019-06-26T11:53:21.086-0400 I CONTROL  [initandlisten] options: {}
2019-06-26T11:53:21.086-0400 E STORAGE  [initandlisten] Unable to read the storage engine metadata file: InvalidBSON: invalid bson in element with field name 'engine' in object with unknown _id
2019-06-26T11:53:21.086-0400 F -        [initandlisten] Fatal Assertion 28661 at src/mongo/db/storage/storage_engine_metadata.cpp 93
2019-06-26T11:53:21.086-0400 F -        [initandlisten] ***aborting after fassert() failure

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