[SERVER-22644] Overriding the Error object causes infinite recursion Created: 16/Feb/16  Updated: 05/Apr/17  Resolved: 07/Nov/16

Status: Closed
Project: Core Server
Component/s: JavaScript
Affects Version/s: 3.3.1
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Robert Guo (Inactive) Assignee: DO NOT USE - Backlog - Platform Team
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-22688 Provide a setParameter and shell opti... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:
Linked BF Score: 0

 Description   

Running the following code on OS X triggers a InternalError: too much recursion. But on Ubuntu the recursion does not terminate and the process is killed in a few minutes for consuming too much memory.

Error = assert.doesNotThrow;
assert.commandWorked(0);

stacktrace on OS X; on Ubuntu it's the same minus the last line:

assert: threw unexpected exception: TypeError: func.apply is not a function : undefined
assert: threw unexpected exception: TypeError: func.apply is not a function : undefined
assert: threw unexpected exception: TypeError: func.apply is not a function : undefined
assert: threw unexpected exception: TypeError: func.apply is not a function : undefined
...... (roughly 880 lines on OS X)
2016-02-16T14:59:49.917-0500 E QUERY    [thread1] warning: log line attempted (78kB) over max size (10kB), printing beginning and end ... InternalError: too much recursion :

ulimit -s is 8192 for both OSes.



 Comments   
Comment by Mira Carey [ 07/Nov/16 ]

Marking this "Works as Designed" after SERVER-22688.

If jstestfuzz wants to avoid oom's in these kind of situations, we should pass the --jsHeapLimitMB parameter to the shell to capture the memory growth before the OS.

Comment by Mira Carey [ 16/Feb/16 ]

It looks like spidermonkey's recursion checker can be circumvented by try catch loops and exceptions.

A simple repro that hits our memory limit (rather than getting oom killed) server side:

db.eval(function() {
 
function a(func, params, msg) {
    try {
        func.apply(null, params);
    } catch (e) {
        b('error');
    }
}
 
function b(msg) {
    var v = a(msg);
 
    throw v;
}
 
b('foo');
 
});

So, on the one hand, this seems like less of a real problem (it can't actually cause a crash server side), but more of an annoyance shell side. Barring making invasive improvements to spidermonkey, our best bet would be to add a memory limit parameter to the server/shell, which would let us set a limit for tests to catch this sort of thing.

Alternatively, we could pick a hard memory limit shell side as well (though this has some practical downsides for users).

Generated at Thu Feb 08 04:01:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.