On Sat, Nov 9, 2013 at 9:49 PM, Peter Bauer <p...@gas-o-lution.com> wrote: > Hi, > > I have some nodejs-program which uses up all memory available. When calling > gc frequently, the problem can be avoided. But whithout gc > the problem occurs regardless of architecture and node version (tried 0.10.5 > and successors/linux windows arm) > On linux, in order to avoid machine lock-up, using ulimit -v 2000000 (Thats > something like 2 GB), I get the msg > FATAL ERROR: Malloced operator new Allocation failed - process out of memory > (If I dont use ulimit, node will just use up all > available memory and swap-space, and you have to drink coffee until machine > settles down to usable state) > > When debugging with gdb and setting bp in .../v8/src/allocation.cc:41, I get > a giantic stack-trace, which starts like that: > #0 v8::internal::Malloced::New (size=1048576) at > ../deps/v8/src/allocation.cc:41 > #1 0x0000000000bf2032 in v8::internal::Zone::NewSegment > (this=0x7ffffffeeda8, size=1048576) at ../deps/v8/src/zone.cc:90 > #2 0x0000000000bf239b in v8::internal::Zone::NewExpand > (this=0x7ffffffeeda8, size=120) at ../deps/v8/src/zone.cc:196 > #3 0x000000000095b39d in v8::internal::Zone::New (this=0x7ffffffeeda8, > size=120) at ../deps/v8/src/zone-inl.h:59 > #4 0x000000000095b437 in v8::internal::ZoneObject::operator new (size=120, > zone=0x7ffffffeeda8) at ../deps/v8/src/zone-inl.h:98 > #5 0x0000000000a27fc4 in v8::internal::HEnvironment::AddIncomingEdge > (this=0x7ffff3ea9dc8, block=0x7ffff3ea9b90, other=0x7ffff3d744a0) > at ../deps/v8/src/hydrogen.cc:9481 > #6 0x0000000000a005da in v8::internal::HBasicBlock::RegisterPredecessor > (this=0x7ffff3ea9b90, pred=0x7ffff3d5b930) at ../deps/v8/src/hydrogen.cc:274 > #7 0x00000000009ffe35 in v8::internal::HBasicBlock::Finish > (this=0x7ffff3d5b930, end=0x7ffff3eb1db0) at ../deps/v8/src/hydrogen.cc:163 > #8 0x00000000009fff5a in v8::internal::HBasicBlock::Goto > (this=0x7ffff3d5b930, block=0x7ffff3ea9b90, state=0x0) at > ../deps/v8/src/hydrogen.cc:179 > #9 0x0000000000a019cc in v8::internal::HGraphBuilder::CreateJoin > (this=0x21b3000, first=0x7ffff3e89d38, second=0x7ffff3d5b930, join_id=...) > at ../deps/v8/src/hydrogen.cc:647 > #10 0x0000000000a0cb6b in v8::internal::HGraphBuilder::VisitIfStatement > (this=0x21b3000, stmt=0x1998d80) at ../deps/v8/src/hydrogen.cc:3995 > #11 0x0000000000ccd594 in v8::internal::IfStatement::Accept (this=0x1998d80, > v=0x21b3000) at ../deps/v8/src/ast.cc:49 > #12 0x00000000009c1729 in v8::internal::AstVisitor::Visit (this=0x21b3000, > node=0x1998d80) at ../deps/v8/src/ast.h:2486 > #13 0x0000000000a0c411 in v8::internal::HGraphBuilder::VisitStatements > (this=0x21b3000, statements=0x1996a50) at ../deps/v8/src/hydrogen.cc:3906 > #14 0x0000000000a0c638 in v8::internal::HGraphBuilder::VisitBlock > (this=0x21b3000, stmt=0x1996a20) at ../deps/v8/src/hydrogen.cc:3936 > #15 0x0000000000ccd502 in v8::internal::Block::Accept (this=0x1996a20, > v=0x21b3000) at ../deps/v8/src/ast.cc:49 > #16 0x00000000009c1729 in v8::internal::AstVisitor::Visit (this=0x21b3000, > node=0x1996a20) at ../deps/v8/src/ast.h:2486 > #17 0x0000000000a0ca91 in v8::internal::HGraphBuilder::VisitIfStatement > (this=0x21b3000, stmt=0x19991c8) at ../deps/v8/src/hydrogen.cc:3980 > #18 0x0000000000ccd594 in v8::internal::IfStatement::Accept (this=0x19991c8, > v=0x21b3000) at ../deps/v8/src/ast.cc:49 > #19 0x00000000009c1729 in v8::internal::AstVisitor::Visit (this=0x21b3000, > node=0x19991c8) at ../deps/v8/src/ast.h:2486 > > which continues up to a deepth of > > #1469 0x0000000000000000 in ?? () > with last non ?? > #1326 0x0000000000b4b560 in v8::internal::Runtime_LazyRecompile (args=..., > isolate=0x130d070) at ../deps/v8/src/runtime.cc:7917 > > so this looks to me like some endless recursion in my (its actually a > library I'm using (sqlite emscripten js version)) program. > > What I would like to do is to turn this error somehow in a > javascript-stacktrace to be able to figure out where that happens. So is > there some easy way to make > that thing throw an exception into my javascript-code? While testing I could > also change the code in allocation.cc but coz I'm not familiar with > node/v8 I would appreciate some help or advice.... > > Cheers, Peter
If you always get the same stack trace (or at least, always one that starts from Runtime_LazyRecompile), then you're feeding V8 a script that's apparently too big to parse. You mention it's an emscripten-compiled version of sqlite so that doesn't sound too implausible. There's no way to turn that out-of-memory error into a JS stack trace. You could try a newer version of node.js if you haven't already. v0.11.8 is the latest development release as of this writing and ships with V8 3.21.18. -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
