Process crashed/aborted by SIG6 - Memory Leak?

[rohit12sh]

Node processing is getting killed/aborted by server after 30-40min of running:

OS: Red Hat Enterprise Linux Server release 6.5
Arch: x86_64
Kernel: 2.6.32-431.20.3.el6.x86_64

Process /bin/node was killed by signal 6 (SIGABRT)
Program terminated with signal 6, Aborted.
#0 0x000000396c00f5db in raise () from /lib64/libpthread.so.0

Not sure where and why the program is getting aborted by SIG6.

Most likely it is due to Memory Leak with Strong-Oracle. When assigning more memory to Node.js, the process runs fine.

[rohit12sh]

Update: I am getting this in stacktrace when my Node process fails.

PID 30415 received SIGSEGV for address: 0x1ab4c9600019
/app/node_modules/strong-oracle/node_modules/segfault-handler/build/Release/segfault-handler.node(+0x1646)[0x7f8cce857646]
/lib64/libpthread.so.0[0x396c00f710]
node(_ZN2v88internal20MarkCompactCollector13MigrateObjectEPhS2_iNS0_15AllocationSpaceE+0x16e)[0x7ecc5e]
node(_ZN2v88internal20MarkCompactCollector27EvacuateLiveObjectsFromPageEPNS0_4PageE+0x1e2)[0x7ed062]
node(_ZN2v88internal20MarkCompactCollector13EvacuatePagesEv+0x63)[0x7ed2c3]
node(_ZN2v88internal20MarkCompactCollector29EvacuateNewSpaceAndCandidatesEv+0xa4)[0x7ed764]
node(_ZN2v88internal20MarkCompactCollector11SweepSpacesEv+0xab)[0x7ee8ab]
node(_ZN2v88internal20MarkCompactCollector14CollectGarbageEv+0x2a)[0x7f0cba]
node(_ZN2v88internal4Heap11MarkCompactEPNS0_8GCTracerE+0x75)[0x752a75]
node(_ZN2v88internal4Heap24PerformGarbageCollectionENS0_16GarbageCollectorEPNS0_8GCTracerE+0x3c4)[0x765c74]
node(_ZN2v88internal4Heap14CollectGarbageENS0_15AllocationSpaceENS0_16GarbageCollectorEPKcS5_+0x154)[0x766064]
node(_ZN2v88internal4Heap17CollectAllGarbageEiPKc+0x87)[0x766387]
node(_ZN2v88internal9Execution25HandleStackGuardInterruptEPNS0_7IsolateE+0x279)[0x729da9]
[0x1f5a38006362]

[raymondfeng]

@rohit12sh Which node version do you use?

@bnoordhuis Any clue?

[rohit12sh]

v0.10.36

[rohit12sh]

Is there a way to fetch nextRows without going into recursion? I have a feeling that holding data in memory causes memory leak due to continous recursion.

[bnoordhuis]

@raymondfeng Not really. It looks like memory corruption.

@rohit12sh What does find /app/node_modules -name \*.node print? You mention you suspect recursion. Does doubling or quadrupling ulimit -s make a difference?

[rohit12sh]

@bnoordhuis : find command prints the below:
node_modules/strong-oracle/node_modules/segfault-handler/build/Release/obj.target/segfault-handler.node
node_modules/strong-oracle/node_modules/segfault-handler/build/Release/segfault-handler.node
node_modules/strong-oracle/build/Release/obj.target/oracle_bindings.node
node_modules/strong-oracle/build/Release/oracle_bindings.node

ulimit -s gives 10240

I am not getting stackOverflow or recursion depth exceeded kind of error

[soyuka]

I had done some tests with strong-oracle vs the new oracledb about memory. I need to put them back together, but I remember that strong-oracle was indeed using more memory.
Note that I'm closing opened connections in both cases and not using the reader, might be v1.6 though.