Possible memory leak in ConnectionPool (3.6.x)

Working with Data Drivers
,
1

I use mongodb for my Discord Bot, and just recently I had an issue where the the process running the driver would keep growing in memory size. This is a new problem as far as I can tell, or at least it hadn’t caused any isses before this. I looked at heap dumps, at it appears that there are many many objects and closures being created in a denque inside the ConnectionPool object. When looking at all of these objects inside the denque, it appears that every one only has one method, callback. This has another function in its context (like a scope from what I understand) called callback, which is an instance of callbackWithRetry. This chain continues far down the line until eventually the only things left inside its context are a resolve() and reject() method. There are thousands of these callback chains, each taking up around 4 KB of memory.

image
image653×722 20.9 KB

Tracing down the line, here’s what each level of callback nesting has that might help identify what each is called for.

  1. Context has a this variable which is the ConnectionPool (seems to be the class scope)
  2. Context has variables named topology, inTransaction, operation, and serverSelectionOptions
  3. Context has variables named owner, session, and operation
  4. Context has a this variable set to a Cursor, as well as a cursor variable also referencing the same Cursor. This context also has a callback as well as a queryCallback
  5. Context has a variable self set to that same Cursor, with no other variables except callback
  6. Context has variable cursor set to that same Cursor
  7. Empty except for callback variable
  8. Empty except for callback variable
  9. Context has variables named owner, session, and operation (reference different variables than level 3)
  10. Context has resolve and reject variables and nothing else (no callback variable, end of chain)

I do not know whether this is normal operation or not, but I found it very interesting that there would be such a long chain of callbacks, and so many of them all put together. The process just keeps taking memory until it’s killed. Does anyone have any insights as to what’s going on here, and how it can be mitigated or fixed?

2

Hey @jchanes04, thanks for bringing this to our attention, I’m sorry I don’t have an immediate answer for you but we’ll be investigating the cause of this so I’ve made a JIRA ticket to track here NODE-3383. You can make an account on our JIRA to track the progress or even provide us with more details about the potential cause of the error. Are you able to identify what API might be causing the issue? (Like an insert or find etc.?). And what driver version are you using?

We can keep the thread going here but moving to the comments section of the JIRA would help us best track the information. Thanks again!