balderdashy / balderdashy/sails
Difficulty debugging a memory Leak
- Dominant language
- JavaScript
- Stars
- 22.8k
- Forks
- 1.9k
- PR merge metrics
- No merged PRs in 30d
Description
**Node version**: v12.22.9
**Sails version** _(sails)_: 0.12.14
**ORM hook version** _(sails-hook-orm)_: 1.0.9
**Sockets hook version** _(sails-hook-sockets)_: 0.13.11
**Organics hook version** _(sails-hook-organics)_: --
**Grunt hook version** _(sails-hook-grunt)_: --
**Uploads hook version** _(sails-hook-uploads)_: --
**DB adapter & version** _(e.g. sails-mysql@5.55.5)_: sails-postgresql@0.11.4
**Skipper adapter & version** _(e.g. skipper-s3@5.55.5)_: skipper@0.7.6
I manage a Node.js server that tipically occupies ~65MB of RAM. After opening a certain page, the memory usage increases drastically, until it freezes the PC or throws a FATAL ERROR with a heap related error. In the second screenshot we can note an array emerging and occupying a large portion of memory. I found an object that is really present in the code (that purple providerinformation in the inferior part). But it doesn't tell much, it's a just a model name and page name. In an older version of the code that is running on prd server it doesn't happen so I don't think it is caused by Sails, since I didn't update sails (at least not in package.json) and I didn't find memory leak issues in my node version (the server runs an older version). How can I proceed?
Notes:
- Even deactivating scheduled services and not making new requests the memory usage increases in the same behaviour
- The problem only starts after reaching a specific page
- The problem happens when I connect to dev db (that is populated with hundreds of tuples while my local server has very few)


Error message:
>
> <--- Last few GCs --->
>
> [11733:0x563472f0af10] 182853 ms: Scavenge 2037.3 (2046.9) -> 2034.8 (2047.6) MB, 8.2 / 0.0 ms (average mu = 0.137, current mu = 0.087) allocation failure
> [11733:0x563472f0af10] 182873 ms: Scavenge 2038.1 (2047.6) -> 2035.5 (2048.1) MB, 8.6 / 0.0 ms (average mu = 0.137, current mu = 0.087) allocation failure
> [11733:0x563472f0af10] 182894 ms: Scavenge 2038.7 (2048.1) -> 2036.2 (2056.9) MB, 9.6 / 0.0 ms (average mu = 0.137, current mu = 0.087) allocation failure
>
>
>
> <--- JS stacktrace --->
>
> ==== JS stack trace =========================================
>
> Security context: 0x27d5da31b9a1
> 0: builtin exit frame: stringify(this=0x27d5da30b729 ,2,0x29315ef004b1 ,0x19341927f741 ,0x27d5da30b729 )
>
> 1: json [0xa7e9a32a209] [/home/user/Desktop/tog/node_modules/@sailshq/express/lib/response.js:231] [bytecode=0x1d029d7bc129 offset=156](this=0x21ddafea9a29 ,0x19...
>
> FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
> 1: 0x7fa5b026c3cc node::Abort() [/lib/x86_64-linux-gnu/libnode.so.72]
> 2: 0x7fa5b019c67c [/lib/x86_64-linux-gnu/libnode.so.72]
> 3: 0x7fa5b0641e2a v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/lib/x86_64-linux-gnu/libnode.so.72]
> 4: 0x7fa5b06421e4 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/lib/x86_64-linux-gnu/libnode.so.72]
> 5: 0x7fa5b07f4509 [/lib/x86_64-linux-gnu/libnode.so.72]
> 6: 0x7fa5b0804dc6 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/lib/x86_64-linux-gnu/libnode.so.72]
> 7: 0x7fa5b0805c12 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/lib/x86_64-linux-gnu/libnode.so.72]
> 8: 0x7fa5b0806070 v8::internal::Heap::CollectAllGarbage(int, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/lib/x86_64-linux-gnu/libnode.so.72]
> 9: 0x7fa5b07b5ee8 v8::internal::StackGuard::HandleInterrupts() [/lib/x86_64-linux-gnu/libnode.so.72]
> 10: 0x7fa5b08fb74b v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_(v8::internal::Handle, bool, v8::internal::Handle) [/lib/x86_64-linux-gnu/libnode.so.72]
> 11: 0x7fa5b0900464 v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_(v8::internal::Handle, bool, v8::internal::Handle) [/lib/x86_64-linux-gnu/libnode.so.72]
> 12: 0x7fa5b0900c9f v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_(v8::internal::Handle, bool, v8::internal::Handle) [/lib/x86_64-linux-gnu/libnode.so.72]
> 13: 0x7fa5b0901e2c v8::internal::JsonStringifier::Stringify(v8::internal::Handle, v8::internal::Handle, v8::internal::Handle) [/lib/x86_64-linux-gnu/libnode.so.72]
> 14: 0x7fa5b0901ebf v8::internal::JsonStringify(v8::internal::Isolate*, v8::internal::Handle, v8::internal::Handle, v8::internal::Handle) [/lib/x86_64-linux-gnu/libnode.so.72]
> 15: 0x7fa5b06ef2c6 v8::internal::Builtin_JsonStringify(int, unsigned long*, v8::internal::Isolate*) [/lib/x86_64-linux-gnu/libnode.so.72]
> 16: 0x7fa5b112ec79 [/lib/x86_64-linux-gnu/libnode.so.72]
> [1] 11733 IOT instruction (core dumped) node --inspect app
Contributor guide
Research direction
Reproduce the issue by opening the specific page against the populated development database, then inspect the response path at node_modules/@sailshq/express/lib/response.js:231 using the shown node --inspect entry point. Trace the JSArray[124555] being passed to JSON.stringify and identify the page or query producing it; done means the cause is confirmed with a reproducible diagnosis or fix.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, node.js, postgresql
- Domain
- backend, databases, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100