[SERVER-5843] Possible memory leak in Spider Monkey Created: 14/May/12  Updated: 24/Jun/13  Resolved: 24/Jun/13

Status: Closed
Project: Core Server
Component/s: JavaScript, MapReduce
Affects Version/s: 2.0.4
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Ben Becker Assignee: Tad Marshall
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS X 10.7.3


Operating System: OS X
Participants:

 Description   

The following shell script appears to leak memory in the mongo shell. This is a simplified script to reproduce behavior observed during MapReduce.

> // Fresh start shows the mongo process using 27MB of resident mem.
> result = {};
{ }
> result2 = {};
{ }
> for (i=0;i<640000;i++) {
...     result[i] = i * 3 % i;
...     result2[i] = result + 'aaaaaaaaaaaaaaaaaaaaaaaaa';
...     db.isMaster()
... }
{ "ismaster" : true, "maxBsonObjectSize" : 16777216, "ok" : 1 }
> // At this point, the process is holding on to 268mb of resident mem
> result = 0
0
> result2 = 0
0
> i = 0
0
> gc()
> // At this point, the process is holding onto 186mb of resident mem

This test assumes that removing references to all JS objects and running gc() would allow all memory to be reclaimed. I'm unsure if SM's GC should behave this way.



 Comments   
Comment by Tad Marshall [ 24/Jun/13 ]

SpiderMonkey has been replaced by V8.

Comment by Ben Becker [ 15/May/12 ]

Just tested on Linux (Ubuntu 12.04, x64) with similar results.

ben@linux-mobile:~/projects/mongo$ ./mongo
MongoDB shell version: 2.0.4
connecting to: test
> // Res mem is 27mb
> result = {};
{ }
> result2 = {};
{ }
> for (i=0;i<640000;i++) {
...     result[i] = i * 3 % i;
...     result2[i] = result + 'aaaaaaaaaaaaaaaaaaaaaaaaa';
...     db.isMaster()
... }
{ "ismaster" : true, "maxBsonObjectSize" : 16777216, "ok" : 1 }
> // Res mem is 285MB
> result = 0;
0
> result2 = 0;
0
> i = 0
0
> gc()
> // Res mem is 258MB (note 258MB vs. 285MB)

The following test is slightly modified to iterate 6.4M times vs. 640k, which should produce an OOM error from the JS engine (at which point RSS is ~1GB). Mostly tested on MacOS. For some reason this didn't give an OOM the first time I ran it on Linux (mem capped out at ~1GB, but it kept running).

result = {};
result2 = {};
for (i=0;i<6400000;i++) {
    result[i] = i * 3 % i;
    result2[i] = result + 'aaaaaaaaaaaaaaaaaaaaaaaaa';
    db.isMaster()
}
> 

I've been seeing this produce an OOM error when you run the gc() command, and it doesn't free up anything.

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