[SERVER-14014] Mongodb Segmentation fault Created: 21/May/14  Updated: 10/Dec/14  Resolved: 22/May/14

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: 2.6.0
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Pontus Naimell Assignee: Ramon Fernandez Marina
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File mongocrash.txt    
Issue Links:
Duplicate
duplicates SERVER-13516 Array updates on documents with more ... Closed
Operating System: Linux
Participants:

 Description   

Running this script caused a seg fault on 2.6.0:

db.theCollection.find({}, { pro:1, id: 1, title: 1, places:1 }).forEach(
function(z) {
	z.places.forEach(
		function(p){
			print(z.title+' - '+p.title+' # '+p.gwid);
			db.theCollection.update(
				{ 'places.gwid': p.gwid},
				{  
					$set: {
						'places.$.pro': z.pro
					}
				}
			)
		}
	)
	print(z.id+' - '+z.title+' '+z.places.length);
})

Maybe not very good to iterate like this but a seg fault is not good.
I guess that i exceeded the number of threads for the system.
Attatched script and logfile



 Comments   
Comment by Ramon Fernandez Marina [ 22/May/14 ]

pontus I'm able to reproduce the segfault using 2.6.0. Looks like you're running into SERVER-13516, where updating an array with more than 128 BSON elements causes mongod to crash. This issue has been fixed in 2.6.1, so I'd recommend you upgrade at your earliest convenience.

Comment by Pontus Naimell [ 22/May/14 ]

The log really says nothing else of interest

Many of these
2014-05-21T07:56:04.874+0000 [initandlisten] connection accepted from zzzzz:33779 #209768 (23 connections now open)
2014-05-21T07:56:04.876+0000 [conn209768] authenticate db: local

{ authenticate: 1, nonce: "xxx", user: "__system", key: "xxx" }

2014-05-21T07:56:11.212+0000 [conn209501] SEVERE: Invalid access at address: 0x20039e0e02

Looking further back
The "connection accepted" repeats until this is printed
2014-05-21T07:51:19.207+0000 [clientcursormon] mem (MB) res:2092 virt:21463
2014-05-21T07:51:19.207+0000 [clientcursormon] mapped (incl journal view):20696
2014-05-21T07:51:19.207+0000 [clientcursormon] connections:23
2014-05-21T07:51:19.207+0000 [clientcursormon] replication threads:32

Further back more "connection accepted". This system is under development right now so there is no real usage right now.
I went further back in time and memory/connections/threads does not change.

The only SEVERE in the logfile is the one i sent you

My estimates on the collection size looks like this.
theCollection, about 60 objects (82 in total but only 60 are holding larger arrays)
theArray, average 80 object

No core dumped

{
"ns" : "XXX.YYY",
"count" : 82,
"size" : 15838768,
"avgObjSize" : 193155,
"storageSize" : 18108416,
"numExtents" : 6,
"nindexes" : 2,
"lastExtentSize" : 7651328,
"paddingFactor" : 1.0770000000000253,
"systemFlags" : 1,
"userFlags" : 1,
"totalIndexSize" : 16352,
"indexSizes" :

{ "_id_" : 8176, "lonlat_2dsphere" : 8176 }

,
"ok" : 1
}

Comment by Ramon Fernandez Marina [ 21/May/14 ]

Hi Pontus,

I'm unable to reproduce the behavior you describe on 2.6.0 or 2.6.1 using a collection with 1000 sample documents. How many documents do you have in your collection? Also, can you please send us some sample documents? For example:

db.theCollection.find().limit(5).pretty()

The log you sent is truncated, and may be useful to see if there are some other error messages earlier that might help us understand what's going on – can you send us a complete log as well?

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