When I open the Collections for a very large database, Robomongo logs the following error in /tmp/robomongo.log and the list of collections does not open:
Thu Feb 13 13:15:03.382 Assertion: 13111:wrong type for field (count) 1 != 16
0x695a56 0x68fd19 0x68fe3c 0x56321b 0x61f188 0x60c11a 0x612f79 0x613314 0x5efc7f 0x7f86d40ad009 0x7f86d40ad8bc 0x60a021 0x7f86d30af93c 0x7f86d30b5106 0x7f86d40a04c4 0x7f86d40a49b9 0x7f86d40efdc3 0x7f86d15076f2 0x7f86d150b568 0x7f86d150b71c
/home/cschwarz/robomongo-0.8.4-x86_64/bin/robomongo(_ZN5mongo15printStackTraceERSo+0x26) [0x695a56]
/home/cschwarz/robomongo-0.8.4-x86_64/bin/robomongo(_ZN5mongo11msgassertedEiPKc+0xa9) [0x68fd19]
/home/cschwarz/robomongo-0.8.4-x86_64/bin/robomongo() [0x68fe3c]
/home/cschwarz/robomongo-0.8.4-x86_64/bin/robomongo(_ZNK5mongo11BSONElement3chkEi+0x12b) [0x56321b]
/home/cschwarz/robomongo-0.8.4-x86_64/bin/robomongo(_ZN9Robomongo9BsonUtils6detail8getFieldIiEET_RKN5mongo11BSONElementE+0x18) [0x61f188]
/home/cschwarz/robomongo-0.8.4-x86_64/bin/robomongo(_ZN9Robomongo19MongoCollectionInfoC1EN5mongo7BSONObjE+0x17a) [0x60c11a]
/home/cschwarz/robomongo-0.8.4-x86_64/bin/robomongo(_ZN9Robomongo11MongoClient19runCollStatsCommandERKSs+0x499) [0x612f79]
/home/cschwarz/robomongo-0.8.4-x86_64/bin/robomongo(_ZN9Robomongo11MongoClient19runCollStatsCommandERKSt6vectorISsSaISsEE+0xa4) [0x613314]
/home/cschwarz/robomongo-0.8.4-x86_64/bin/robomongo(_ZN9Robomongo11MongoWorker6handleEPNS_26LoadCollectionNamesRequestE+0x7f) [0x5efc7f]
/home/cschwarz/robomongo-0.8.4-x86_64/bin/../lib/libQt5Core.so.5(_ZNK11QMetaMethod6invokeEP7QObjectN2Qt14ConnectionTypeE22QGenericReturnArgument16QGenericArgumentS5_S5_S5_S5_S5_S5_S5_S5_S5_+0x579) [0x7f86d40ad009]
/home/cschwarz/robomongo-0.8.4-x86_64/bin/../lib/libQt5Core.so.5(_ZN11QMetaObject12invokeMethodEP7QObjectPKcN2Qt14ConnectionTypeE22QGenericReturnArgument16QGenericArgumentS7_S7_S7_S7_S7_S7_S7_S7_S7_+0x51c) [0x7f86d40ad8bc]
/home/cschwarz/robomongo-0.8.4-x86_64/bin/robomongo(_ZN9Robomongo18EventBusDispatcher5eventEP6QEvent+0x261) [0x60a021]
/home/cschwarz/robomongo-0.8.4-x86_64/bin/../lib/libQt5Widgets.so.5(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0xac) [0x7f86d30af93c]
/home/cschwarz/robomongo-0.8.4-x86_64/bin/../lib/libQt5Widgets.so.5(_ZN12QApplication6notifyEP7QObjectP6QEvent+0x356) [0x7f86d30b5106]
/home/cschwarz/robomongo-0.8.4-x86_64/bin/../lib/libQt5Core.so.5(_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent+0x84) [0x7f86d40a04c4]
/home/cschwarz/robomongo-0.8.4-x86_64/bin/../lib/libQt5Core.so.5(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData+0x279) [0x7f86d40a49b9]
/home/cschwarz/robomongo-0.8.4-x86_64/bin/../lib/libQt5Core.so.5(+0x2b8dc3) [0x7f86d40efdc3]
/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1f2) [0x7f86d15076f2]
/lib/libglib-2.0.so.0(+0x42568) [0x7f86d150b568]
/lib/libglib-2.0.so.0(g_main_context_iteration+0x6c) [0x7f86d150b71c]
Thu Feb 13 13:15:03.386 ERROR: [Robomongo] wrong type for field (count) 1 != 16
Same for me.
It better to use stats() and not count(), specially for large collections.
@cschwarz-inco @atenenb Can you please provide some example stats() output for a database where you encounter this problem, as well as the MongoDB server version? Does this appear to be an issue with the number of collections, or the number of documents in the collections?
The wrong type for field error is referring to BSON types. It seems like an int32 (type 16) was expected but a double (type 1) was found instead.
It looks like the collection counts are coming from stats() but aren't expected to be more than an int32 .. i.e. 2,147,483,647 documents. This could also be an issue with the server returning a double rather than an int32.
That seems like a straightforward fix, but would need to be sure it's the problem you're encountering. Any extra details on how to reproduce the issue appreciated :)
Thanks!
The MongoDB server version is actually TokuMX 1.3.2:
"version" : "2.4.7",
"tokumxVersion" : "1.3.2",
The offending database has been deleted since then but according to my calculations there were as much as 7,008,000,000 documents in one particular collection. This number definitely does not fit in a 32 bit integer.
Because other databases on this server do work with RoboMongo, I assume that the database returns int32 types when the number of documents is less than 2^32 and double (actually I would assume int64) when the number of documents exceeds this number.
@cschwarz-inco Thanks for confirming, will work on a patch for this.
I was able to reproduce the problem with a new database, this one has "only" 1 billion documents so that doesn't seem to explain the int32 limitation.
The one thig I see that looks suspicious is:
"nscanned" : NumberLong(1088640102),
db.printCollectionStats() gives:
{
"ns" : "exampledb.largecoll",
"count" : 1088595510,
"nindexes" : 3,
"nindexesbeingbuilt" : 3,
"size" : 309521605126,
"storageSize" : 31356616704,
"totalIndexSize" : 119036630944,
"totalIndexStorageSize" : 12646378496,
"indexDetails" : [
{
"name" : "_id_",
"count" : 1088595510,
"size" : 309521605126,
"avgObjSize" : 284.3311425434779,
"storageSize" : 31356616704,
"pageSize" : 4194304,
"readPageSize" : 65536,
"compression" : "zlib",
"queries" : 2,
"nscanned" : NumberLong(1088640102),
"nscannedObjects" : 0,
"inserts" : 0,
"deletes" : 0
},
{
"name" : "index_one",
"count" : 1037014124,
"size" : 58072790944,
"avgObjSize" : 56,
"storageSize" : 5221908480,
"pageSize" : 4194304,
"readPageSize" : 65536,
"compression" : "zlib",
"queries" : 0,
"nscanned" : 0,
"nscannedObjects" : 0,
"inserts" : 0,
"deletes" : 0
},
{
"name" : "index_two",
"count" : 1088640000,
"size" : 60963840000,
"avgObjSize" : 56,
"storageSize" : 7424470016,
"pageSize" : 4194304,
"readPageSize" : 65536,
"compression" : "zlib",
"queries" : 0,
"nscanned" : 0,
"nscannedObjects" : 0,
"inserts" : 0,
"deletes" : 0
}
],
"ok" : 1
}
@cschwarz-inco This may also be a difference in the stats() results returned by TokuMX. I'll have to generate some test data to reproduce the problem in order to know the patch is good :).
Hi Stephen,
The problem also might be because we had a huge collection. More that 2B
documents.
On Sat, Jun 14, 2014 at 12:07 AM, Stephen Steneker <[email protected]
wrote:
@cschwarz-inco https://github.com/cschwarz-inco This may also be a
difference in the stats() results returned by TokuMX. I'll have to generate
some test data to reproduce the problem in order to know the patch is good
:).—
Reply to this email directly or view it on GitHub
https://github.com/paralect/robomongo/issues/475#issuecomment-46059918.
@atenenb Yes, I'd like to test both scenarios mentioned in this issue:
.. as well as making sure this doesn't break for the normal collection.stats() value which is expected to be an int32.
Just want to note that I'm seeing the same bug in a similar situation: a TokuMX install with a collection that contains > 1B documents. Robomongo was working fine before I added this collection
I've replicated the same problem, Mongo 2.6.4 on a 7 shard (each with a primary, secondary, arbiter) cluster. We have a collection with 1.1 billion records and get this error. Btw, MongoVue can read this without problems. Also, a full validation was run on all collections in the DB and checked out ok. Robomongo is a great tool and I really hope this bug gets fixed. Here are the stats:
{
"raw" : {
"Omitted1" : {
"db" : "ren_agg",
"collections" : 5,
"objects" : 156233215,
"avgObjSize" : 112.0085522403159,
"dataSize" : 17499456224,
"storageSize" : 20248334240,
"numExtents" : 53,
"indexes" : 12,
"indexSize" : 37068078992,
"fileSize" : 68619862016,
"nsSizeMB" : 16,
"dataFileVersion" : {
"major" : 4,
"minor" : 5
},
"extentFreeList" : {
"num" : 0,
"totalSize" : 0
},
"ok" : 1
},
"Omitted2" : {
"db" : "ren_agg",
"collections" : 5,
"objects" : 155752666,
"avgObjSize" : 112.1187976840153,
"dataSize" : 17462801648,
"storageSize" : 20299132832,
"numExtents" : 54,
"indexes" : 12,
"indexSize" : 37021492144,
"fileSize" : 68619862016,
"nsSizeMB" : 16,
"dataFileVersion" : {
"major" : 4,
"minor" : 5
},
"extentFreeList" : {
"num" : 0,
"totalSize" : 0
},
"ok" : 1
},
"Omitted3" : {
"db" : "ren_agg",
"collections" : 5,
"objects" : 157216162,
"avgObjSize" : 112.1164628354177,
"dataSize" : 17626519984,
"storageSize" : 20299132832,
"numExtents" : 54,
"indexes" : 12,
"indexSize" : 35652829744,
"fileSize" : 66473426944,
"nsSizeMB" : 16,
"dataFileVersion" : {
"major" : 4,
"minor" : 5
},
"extentFreeList" : {
"num" : 0,
"totalSize" : 0
},
"ok" : 1
},
"Omitted4" : {
"db" : "ren_agg",
"collections" : 5,
"objects" : 154805743,
"avgObjSize" : 112.0064230175233,
"dataSize" : 17339237536,
"storageSize" : 20248334240,
"numExtents" : 53,
"indexes" : 12,
"indexSize" : 30728130608,
"fileSize" : 62180556800,
"nsSizeMB" : 16,
"dataFileVersion" : {
"major" : 4,
"minor" : 5
},
"extentFreeList" : {
"num" : 0,
"totalSize" : 0
},
"ok" : 1
},
"Omitted5" : {
"db" : "ren_agg",
"collections" : 5,
"objects" : 154302956,
"avgObjSize" : 112.0075488897309,
"dataSize" : 17283095888,
"storageSize" : 20248334240,
"numExtents" : 53,
"indexes" : 12,
"indexSize" : 34924683360,
"fileSize" : 66473426944,
"nsSizeMB" : 16,
"dataFileVersion" : {
"major" : 4,
"minor" : 5
},
"extentFreeList" : {
"num" : 0,
"totalSize" : 0
},
"ok" : 1
},
"Omitted6" : {
"db" : "a_db",
"collections" : 5,
"objects" : 155662300,
"avgObjSize" : 111.8967036719874,
"dataSize" : 17418098256,
"storageSize" : 20210708384,
"numExtents" : 52,
"indexes" : 12,
"indexSize" : 30838629248,
"fileSize" : 62180556800,
"nsSizeMB" : 16,
"dataFileVersion" : {
"major" : 4,
"minor" : 5
},
"extentFreeList" : {
"num" : 0,
"totalSize" : 0
},
"ok" : 1
},
"Omitted7" : {
"db" : "a_db",
"collections" : 5,
"objects" : 155901442,
"avgObjSize" : 111.8962635894029,
"dataSize" : 17444788848,
"storageSize" : 20248334240,
"numExtents" : 53,
"indexes" : 12,
"indexSize" : 32729214784,
"fileSize" : 64326991872,
"nsSizeMB" : 16,
"dataFileVersion" : {
"major" : 4,
"minor" : 5
},
"extentFreeList" : {
"num" : 0,
"totalSize" : 0
},
"ok" : 1
}
},
"objects" : 1089874484,
"avgObjSize" : 111.7141287858612,
"dataSize" : 122073998384,
"storageSize" : 141802311008,
"numExtents" : 372,
"indexes" : 84,
"indexSize" : 238963058880,
"fileSize" : 458874683392,
"extentFreeList" : {
"num" : 0,
"totalSize" : 0
},
"ok" : 1
}
One more piece of information to share... I have a similar dev environment that has 1.03 billion records and do NOT get the error. In our environment, the UI problem starts somewhere between 1.03 and 1.08 billion records! This does not support the idea that an int is being blown out.
Is there some progress on this issue? I have the same problem - can't open list of collections in case of a huge DB...
+1
Guys, it seems I have that issue. Robomongo 0.9.0, OS X 10.11.6 (15G1212).
Cannot load list of indexes.
Error:
wrong type for field (background) 16 != 8
A little bit statistic on the collection:
{
"ns" : "messages.messages",
"count" : 6078207,
"size" : 6772252402.0,
"avgObjSize" : 1114,
"storageSize" : 4061638656.0,
"capped" : false,
"wiredTiger" : {
"metadata" : {
"formatVersion" : 1
},
"creationString" : "allocation_size=4KB,app_metadata=(formatVersion=1),block_allocation=best,block_compressor=snappy,cache_resident=0,checkpoint=(WiredTigerCheckpoint.254253=(addr=\"--removed--\",order=254253,time=1482243469,size=4823040000,write_gen=133429490)),checkpoint_lsn=(270304,88759040),checksum=on,collator=,columns=,dictionary=0,format=btree,huffman_key=,huffman_value=,id=148,internal_item_max=0,internal_key_max=0,internal_key_truncate=,internal_page_max=4KB,key_format=q,key_gap=10,leaf_item_max=0,leaf_key_max=0,leaf_page_max=32KB,leaf_value_max=64MB,memory_page_max=10m,os_cache_dirty_max=0,os_cache_max=0,prefix_compression=0,prefix_compression_min=4,split_deepen_min_child=0,split_deepen_per_child=0,split_pct=90,value_format=u,version=(major=1,minor=1)",
"type" : "file",
"uri" : "statistics:table:collection-141--11346734220783974",
"LSM" : {
"bloom filters in the LSM tree" : 0,
"bloom filter false positives" : 0,
"bloom filter hits" : 0,
"bloom filter misses" : 0,
"bloom filter pages evicted from cache" : 0,
"bloom filter pages read into cache" : 0,
"total size of bloom filters" : 0,
"sleep for LSM checkpoint throttle" : 0,
"chunks in the LSM tree" : 0,
"highest merge generation in the LSM tree" : 0,
"queries that could have benefited from a Bloom filter that did not exist" : 0,
"sleep for LSM merge throttle" : 0
},
"block-manager" : {
"file allocation unit size" : 4096,
"blocks allocated" : 134058159,
"checkpoint size" : 4823040000.0,
"allocations requiring file extension" : 327085,
"blocks freed" : 132991642,
"file magic number" : 120897,
"file major version number" : 1,
"minor version number" : 0,
"file bytes available for reuse" : 279973888,
"file size in bytes" : 4061638656.0
},
"btree" : {
"btree checkpoint generation" : 254844,
"column-store variable-size deleted values" : 0,
"column-store fixed-size leaf pages" : 0,
"column-store internal pages" : 0,
"column-store variable-size leaf pages" : 0,
"pages rewritten by compaction" : 0,
"number of key/value pairs" : 0,
"fixed-record size" : 0,
"maximum tree depth" : 4,
"maximum internal page key size" : 368,
"maximum internal page size" : 4096,
"maximum leaf page key size" : 2867,
"maximum leaf page size" : 32768,
"maximum leaf page value size" : 67108864,
"overflow pages" : 0,
"row-store internal pages" : 0,
"row-store leaf pages" : 0
},
"cache" : {
"bytes read into cache" : NumberLong(3718128933581),
"bytes written from cache" : 965904276892.0,
"checkpoint blocked page eviction" : 136,
"unmodified pages evicted" : 171509394,
"page split during eviction deepened the tree" : 3,
"modified pages evicted" : 61288014,
"data source pages selected for eviction unable to be evicted" : 136641,
"hazard pointer blocked page eviction" : 126569,
"internal pages evicted" : 57126,
"pages split during eviction" : 736813,
"in-memory page splits" : 831,
"overflow values cached in memory" : 0,
"pages read into cache" : 233531167,
"overflow pages read into cache" : 0,
"pages written from cache" : 133549569
},
"compression" : {
"raw compression call failed, no additional data available" : 0,
"raw compression call failed, additional data available" : 0,
"raw compression call succeeded" : 0,
"compressed pages read" : 161182032,
"compressed pages written" : 35742315,
"page written failed to compress" : 75974,
"page written was too small to compress" : 97603917
},
"cursor" : {
"create calls" : 24675035,
"insert calls" : 295839289,
"bulk-loaded cursor-insert calls" : 0,
"cursor-insert key and value bytes inserted" : 483479161525.0,
"next calls" : 37151533,
"prev calls" : 1,
"remove calls" : 87791950,
"cursor-remove key bytes removed" : 428840937,
"reset calls" : 1513700304.0,
"search calls" : 1377485639.0,
"search near calls" : 194159,
"update calls" : 0,
"cursor-update value bytes updated" : 0
},
"reconciliation" : {
"dictionary matches" : 0,
"internal page multi-block writes" : 471927,
"leaf page multi-block writes" : 828602,
"maximum blocks required for a page" : 30,
"internal-page overflow keys" : 0,
"leaf-page overflow keys" : 0,
"overflow values written" : 0,
"pages deleted" : 4706206,
"page checksum matches" : 70608067,
"page reconciliation calls" : 86020051,
"page reconciliation calls for eviction" : 38018959,
"leaf page key bytes discarded using prefix compression" : 0,
"internal page key bytes discarded using suffix compression" : 9421135
},
"session" : {
"object compaction" : 0,
"open cursor count" : 24675013
},
"transaction" : {
"update conflicts" : 1695
}
},
"nindexes" : 18,
"totalIndexSize" : 1935286272.0,
"indexSizes" : {
"_id_" : 431480832,
"read-unread" : 63868928,
"flag" : 54910976,
"social-profile" : 30482432,
"network_user_id" : 95297536,
"leads" : 84262912,
"feed" : 25821184,
"real_time_search_id" : 88698880,
"ttl.fast_1" : 26775552,
"status" : 165109760,
"ttl.regular_1" : 59830272,
"received_date" : 155025408,
"network" : 28258304,
"received_date_-1_profile_id_1_feed_type_1" : 378556416,
"profile_id_1_feed_type_1_received_date_-1" : 61808640,
"from_1" : 101285888,
"owner_id" : 35385344,
"replied_idx" : 48427008
},
"ok" : 1.0
}
Same problem with Robomongo 0.9.0 in ubuntu 16.04 64 bits.
Most helpful comment
Guys, it seems I have that issue. Robomongo 0.9.0, OS X 10.11.6 (15G1212).
Cannot load list of indexes.
Error:
wrong type for field (background) 16 != 8
A little bit statistic on the collection: