Extremely high CPU and RAM consumption about intelephense-docs

[bmewburn]

I'll take a closer look, are you able to share your composer.json so I'm testing with similar files?

(By the way, what a strange choice of a language, just why NodeJS? thinking)

It's a well supported, fast, cross platform, async runtime, with lots of open source packages. And with PHP being primarily a web language, users may be already familiar with nodejs and have it installed.

[rosmanov]

I'll take a closer look, are you able to share your composer.json so I'm testing with similar files?

Unfortunately, I can't share composer.json, since it's a private project, and most of the repositories/files are private.

[bmewburn]

Which nodejs version are you using?

[rosmanov]

Which nodejs version are you using?

v8.12.0

---

Some of the composer dependencies:

    "require": {
        "doctrine/inflector": "v1.1.0",
        "illuminate/contracts": "v5.2.21",
        "illuminate/support": "v5.2.21",
        "guzzlehttp/streams": ">=2.1.0",
        "guzzlehttp/guzzle": "~6.3.3",
        "psr/log": "1.0.0",
        "monolog/monolog": "1.18.0",
        "symfony/polyfill-mbstring": "v1.2.0",
        "spomky-labs/base64url": "v1.0.2",
        "justinrainbow/json-schema": "1.5.0",
        "nervetattoo/elasticsearch": "v2.4.1",
        "phpseclib/phpseclib": "2.0.0",
        "wamania/php-stemmer": "1.0",
        "fabiang/xmpp": "0.6.1",
        "iamcal/php-emoji": "dev-master#2a1819b154a7e7351b5abcc398ed8fd261f71f67",
        "endroid/qrcode": "1.7.4",
        "aws/aws-sdk-php": "~3.24.5",
        "phpoffice/phpexcel": "^1.8",
        "amenadiel/jpgraph": "^3.6",
        "phpoffice/phpword": "v0.13.*",
        "salsify/json-streaming-parser": "6.0.3",
        "firebase/php-jwt": "4.0",
        "smi2/phpclickhouse": "1.3.7",
        "google/cloud-pubsub": "^1.0",
        "google/protobuf": "^3.5",
        "google/apiclient": "^2.2",
        "sensiolabs/consul-php-sdk": "^3.0",
        "elasticsearch/elasticsearch": "~6.7.2",
        "gamegos/jws": "~1.0",
        "iamcal/sql-parser": "dev-master#c64f01814811a829f53ca400b80e0e884dc18dff",
        "lightsaml/lightsaml": "^1.4",
        "sebastian/diff": "^3.0",
        "predis/predis": "^1.1",
        "web-token/jwt-signature": "1.0",
        "aerospike/aerospike-client-php": "~7.0",
        "giggsey/libphonenumber-for-php": "8.10.1",
        "myclabs/php-enum": "1.6.4",
        "ongr/elasticsearch-dsl": "6.0.3",
        "symfony/console": "^4.3",
        "phpdocumentor/reflection-docblock": "^4.3",
        "beberlei/assert": "^3.2",
        "ua-parser/uap-php": "^3.8",
        "solodkiy/mysql-error-parser": "^0.1.0",
        "symfony/http-foundation": "4.1.4",
        "spiral/roadrunner": "^1.4",
        "nyholm/psr7": "^1.1",
        "symfony/validator": "^4.3",
        "doctrine/annotations": "^1.7",
        "illuminate/container": " ^5.2",
        "thiagoalessio/tesseract_ocr": "^2.7",
        "textalk/websocket": "^1.2",
        "guzzlehttp/ringphp": "~1.1"
    }

[bmewburn]

Thanks, are you able to try the current LTS version of nodejs (12.x)? Is there any improvement?

[rosmanov]

Thanks, are you able to try the current LTS version of nodejs (12.x)? Is there any improvement?

It feels much better with Node.js version v12.13.0 in the sense that the node process doesn't cause swapping as much.

Still,

• swapping does occur (which is not necessarily bad though...);
• overall indexing time is around 10 minutes;
• 3-4 CPU cores are being fully consumed (during the indexing);
• up to 4G RAM consumption (perhaps, PhpStorm consumes as much, but from what I recorded it didn't exceed 2.5G);
• node process produces a couple of new core dumps after the indexer stops topping CPU and RAM;

I also noticed that X server lagged for a moment when I switched to some activity in Firefox.

Despite of the long indexing time, completion and introspection functionality became available quickly enough (maybe 2 minutes later).

Overall experience is pretty smooth. But I'm still nervous about the absence of control over the CPU and RAM consumption.

Another concern is that the full indexing seems to occur more frequently than needed. For example, when I open a PHP file for the first time in a day, the indexer seems to build the index from scratch.

I'm not sure if I should close the issue. On my relatively powerful desktop, everything seems to work fairly well. But I'm not sure that the same will be true for a laptop at work. Let me check this next week.

[bmewburn]

There's always more optimising to be done. I don't usually test on workspaces larger than about 30k files (magento). The more files the bigger the indexes and symbol table which is all stored in memory.

when I open a PHP file for the first time in a day, the indexer seems to build the index from scratch

It should not have to rebuild the index on each start. It should read the last stored index from disk and then check if the workspace changed since last time. This may mean that there will be some files indexed but it shouldn't be the full workspace. Whenever the version is updated, a full index occurs.

[rosmanov]

There's always more optimising to be done. I don't usually test on workspaces larger than about 30k files (magento). The more files the bigger the indexes and symbol table which is all stored in memory.

Tested on a laptop at work with Node.js vesion v12.13.0. Everything looks good so far.

It should not have to rebuild the index on each start. It should read the last stored index from disk and then check if the workspace changed since last time. This may mean that there will be some files indexed but it shouldn't be the full workspace. Whenever the version is updated, a full index occurs.

Indeed, now I don't notice full index rebuilds. I think I re-installed coc-phpls a few times when I tried different ways to overcome the performance issues.

[rosmanov]

It turns out, intelephense never finishes indexing on my laptop. It runs for some time, then crashes, then re-starts and so on. It produces a core dump similar to what I posted above

I'll try to get more meaningful backtrace. I think it happens when I invoke a "go to definition"/"completion" command while the indexer is running.

EDIT: It crashed exactly at the time when I was writing this message. So it even doesn't depend on my activity in the editor. Ah, and when it crashes, the X server hangs for a second. So it was the crash of the node process that caused the irritating "lags".

EDIT2:

OS: Fedora 31 (Workstation Edition)
Arch: x86_64
Node.js version: v12.13.0
Installed node packages:

nodejs.x86_64                                                                             1:12.13.0-7.fc31                                                                  @updates          
nodejs-debuginfo.x86_64                                                                   1:12.13.1-1.fc31                                                                  @updates-debuginfo
nodejs-debugsource.x86_64                                                                 1:12.13.1-1.fc31                                                                  @updates-debuginfo
nodejs-docs.noarch                                                                        1:12.13.0-7.fc31                                                                  @updates          
nodejs-libs.x86_64                                                                        1:12.13.0-7.fc31                                                                  @updates          
nodesource-release.noarch                                                                 fc31-1                                                                            @System           

[rosmanov]

Here is a better backtrace:

[ruslanosmanov@localhost ~]$ coredumpctl gdb 8068
           PID: 8068 (node)
           UID: 1000 (ruslanosmanov)
           GID: 1000 (ruslanosmanov)
        Signal: 6 (ABRT)
     Timestamp: Wed 2019-12-11 11:53:21 MSK (2min 42s ago)
  Command Line: /usr/bin/node /home/ruslanosmanov/.config/coc/extensions/node_modules/coc-phpls/node_modules/intelephense/lib/intelephense.js --node-ipc --clientProcessId=7478
    Executable: /usr/bin/node
 Control Group: /user.slice/user-1000.slice/[email protected]/gnome-shell-wayland.service
          Unit: [email protected]
     User Unit: gnome-shell-wayland.service
         Slice: user-1000.slice
     Owner UID: 1000 (ruslanosmanov)
       Boot ID: 60324d05a983474b9ba4ed799b3cad63
    Machine ID: 829afe6e46874bf3ae073e260fe1487c
      Hostname: localhost.localdomain
       Storage: /var/lib/systemd/coredump/core.node.1000.60324d05a983474b9ba4ed799b3cad63.8068.1576054401000000000000.lz4
       Message: Process 8068 (node) of user 1000 dumped core.
                
                Stack trace of thread 8068:
                #0  0x00007f4094678625 raise (libc.so.6)
                #1  0x00007f40946618d9 abort (libc.so.6)
                #2  0x00007f409548ea19 _ZN4node5AbortEv (libnode.so.72)
                #3  0x00007f4095490915 _ZN4node12OnFatalErrorEPKcS1_ (libnode.so.72)
                #4  0x00007f40957e09aa _ZN2v85Utils16ReportOOMFailureEPNS_8internal7IsolateEPKcb (libnode.so.72)
                #5  0x00007f40957e0c32 _ZN2v88internal2V823FatalProcessOutOfMemoryEPNS0_7IsolateEPKcb (libnode.so.72)
                #6  0x00007f4095968419 _ZN2v88internal4Heap23FatalProcessOutOfMemoryEPKc (libnode.so.72)
                #7  0x00007f409597df17 _ZN2v88internal4Heap24PerformGarbageCollectionENS0_16GarbageCollectorENS_15GCCallbackFlagsE (libnode.so.72)
                #8  0x00007f409597ec8d _ZN2v88internal4Heap14CollectGarbageENS0_15AllocationSpaceENS0_23GarbageCollectionReasonENS_15GCCallbackFlagsE (libnode.so.72)
                #9  0x00007f409598107c _ZN2v88internal4Heap25AllocateRawWithLightRetryEiNS0_14AllocationTypeENS0_19AllocationAlignmentE (libnode.so.72)
                #10 0x00007f40959813a5 _ZN2v88internal4Heap26AllocateRawWithRetryOrFailEiNS0_14AllocationTypeENS0_19AllocationAlignmentE (libnode.so.72)
                #11 0x00007f409594809d _ZN2v88internal7Factory15NewFillerObjectEibNS0_14AllocationTypeE (libnode.so.72)
                #12 0x00007f4095c6852d _ZN2v88internal33Runtime_AllocateInYoungGenerationEiPmPNS0_7IsolateE (libnode.so.72)
                #13 0x00007f409630c299 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit (libnode.so.72)
                #14 0x00000483b18d0926 n/a (n/a)
                #15 0x00000483b18c98e8 n/a (n/a)
                #16 0x00000483b1b1a29e n/a (n/a)
                #17 0x00000483b1b18c93 n/a (n/a)
                #18 0x00000483b1b18c93 n/a (n/a)
                #19 0x00000483b1b18cf8 n/a (n/a)
                #20 0x00000483b1b18cf8 n/a (n/a)
                #21 0x00000483b1b18c93 n/a (n/a)
                #22 0x00007f409628c8e4 Builtins_InterpreterEntryTrampoline (libnode.so.72)
                #23 0x00000483b1b194e4 n/a (n/a)
                #24 0x00000483b1b18cf8 n/a (n/a)
                #25 0x00000483b1b18cf8 n/a (n/a)
                #26 0x00007f409628c8e4 Builtins_InterpreterEntryTrampoline (libnode.so.72)
                #27 0x00000483b1b19238 n/a (n/a)
                #28 0x00000483b1b18cf8 n/a (n/a)
                #29 0x00000483b1b646cd n/a (n/a)
                #30 0x00007f409628c8e4 Builtins_InterpreterEntryTrampoline (libnode.so.72)
                #31 0x00000483b1b18dd7 n/a (n/a)
                #32 0x00007f409628c8e4 Builtins_InterpreterEntryTrampoline (libnode.so.72)
                #33 0x00007f409628c8e4 Builtins_InterpreterEntryTrampoline (libnode.so.72)
                #34 0x00000483b1babf89 n/a (n/a)
                #35 0x00007f40962b9975 Builtins_GeneratorPrototypeNext (libnode.so.72)
                #36 0x00007f409628c8e4 Builtins_InterpreterEntryTrampoline (libnode.so.72)
                #37 0x00007f40962db392 Builtins_PromiseFulfillReactionJob (libnode.so.72)
                #38 0x00007f40962a8f06 Builtins_RunMicrotasks (libnode.so.72)
                #39 0x00007f4096289e38 Builtins_JSRunMicrotasksEntry (libnode.so.72)
                #40 0x00007f409590cf97 _ZN2v88internal12_GLOBAL__N_16InvokeEPNS0_7IsolateERKNS1_12InvokeParamsE (libnode.so.72)
                #41 0x00007f409590d282 _ZN2v88internal12_GLOBAL__N_118InvokeWithTryCatchEPNS0_7IsolateERKNS1_12InvokeParamsE.constprop.0 (libnode.so.72)
                #42 0x00007f409590d67d _ZN2v88internal9Execution16TryRunMicrotasksEPNS0_7IsolateEPNS0_14MicrotaskQueueEPNS0_11MaybeHandleINS0_6ObjectEEE (libnode.so.72)
                #43 0x00007f409592f084 _ZN2v88internal14MicrotaskQueue13RunMicrotasksEPNS0_7IsolateE (libnode.so.72)
                #44 0x00007f40953e6fd5 _ZN4node21InternalCallbackScope5CloseEv (libnode.so.72)
                #45 0x00007f40953e7414 _ZN4node20InternalMakeCallbackEPNS_11EnvironmentEN2v85LocalINS2_6ObjectEEENS3_INS2_8FunctionEEEiPNS3_INS2_5ValueEEENS_13async_contextE (libnode.so.72)
                #46 0x00007f40953f925f _ZN4node9AsyncWrap12MakeCallbackEN2v85LocalINS1_8FunctionEEEiPNS2_INS1_5ValueEEE (libnode.so.72)
                #47 0x00007f4095491772 _ZN4node2fs13FSReqCallback7ResolveEN2v85LocalINS2_5ValueEEE (libnode.so.72)
                #48 0x00007f409549635e _ZN4node2fs11AfterNoArgsEP7uv_fs_s (libnode.so.72)
                #49 0x00007f40945fc0c5 uv__work_done (libuv.so.1)
                #50 0x00007f40945ff4d8 uv__async_io.part.0 (libuv.so.1)
                #51 0x00007f409460fe00 uv__io_poll (libuv.so.1)
                #52 0x00007f40945ffe7c uv_run (libuv.so.1)
                #53 0x00007f40954ddd12 _ZN4node16NodeMainInstance3RunEv (libnode.so.72)
                #54 0x00007f409545dc41 _ZN4node5StartEiPPc (libnode.so.72)
                #55 0x000055e802e2afde main (node)
                #56 0x00007f40946631a3 __libc_start_main (libc.so.6)
                #57 0x000055e802e2b14e _start (node)
                
                Stack trace of thread 8069:
                #0  0x00007f409473d97e epoll_wait (libc.so.6)
                #1  0x00007f409460fef9 uv__io_poll (libuv.so.1)
                #2  0x00007f40945ffe7c uv_run (libuv.so.1)
                #3  0x00007f4095510a9d _ZZN4node23WorkerThreadsTaskRunner20DelayedTaskScheduler5StartEvENUlPvE_4_FUNES2_ (libnode.so.72)
                #4  0x00007f409480e4e2 start_thread (libpthread.so.0)
                #5  0x00007f409473d643 __clone (libc.so.6)
                
                Stack trace of thread 8075:
                #0  0x00007f40948178f4 do_futex_wait.constprop.0 (libpthread.so.0)
                #1  0x00007f40948179e8 __new_sem_wait_slow.constprop.0 (libpthread.so.0)
                #2  0x00007f409460cbd2 uv_sem_wait (libuv.so.1)
                #3  0x00007f409556fba4 _ZN4node9inspector12_GLOBAL__N_117StartIoThreadMainEPv (libnode.so.72)
                #4  0x00007f409480e4e2 start_thread (libpthread.so.0)
                #5  0x00007f409473d643 __clone (libc.so.6)
                
                Stack trace of thread 8072:
                #0  0x00007f4094814d45 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f409460cb4d uv_cond_wait (libuv.so.1)
                #2  0x00007f409550c7f3 _ZN4node12_GLOBAL__N_1L20PlatformWorkerThreadEPv (libnode.so.72)
                #3  0x00007f409480e4e2 start_thread (libpthread.so.0)
                #4  0x00007f409473d643 __clone (libc.so.6)
                
                Stack trace of thread 8070:
                #0  0x00007f4094814d45 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f409460cb4d uv_cond_wait (libuv.so.1)
                #2  0x00007f409550c7f3 _ZN4node12_GLOBAL__N_1L20PlatformWorkerThreadEPv (libnode.so.72)
                #3  0x00007f409480e4e2 start_thread (libpthread.so.0)
                #4  0x00007f409473d643 __clone (libc.so.6)
                
                Stack trace of thread 8080:
                #0  0x00007f4094814d45 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f409460cb4d uv_cond_wait (libuv.so.1)
                #2  0x00007f40945fbbed worker (libuv.so.1)
                #3  0x00007f409480e4e2 start_thread (libpthread.so.0)
                #4  0x00007f409473d643 __clone (libc.so.6)
                
                Stack trace of thread 8079:
                #0  0x00007f4094814d45 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f409460cb4d uv_cond_wait (libuv.so.1)
                #2  0x00007f40945fbbed worker (libuv.so.1)
                #3  0x00007f409480e4e2 start_thread (libpthread.so.0)
                #4  0x00007f409473d643 __clone (libc.so.6)
                
                Stack trace of thread 8078:
                #0  0x00007f4094814d45 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f409460cb4d uv_cond_wait (libuv.so.1)
                #2  0x00007f40945fbbed worker (libuv.so.1)
                #3  0x00007f409480e4e2 start_thread (libpthread.so.0)
                #4  0x00007f409473d643 __clone (libc.so.6)
                
                Stack trace of thread 8077:
                #0  0x00007f4094814d45 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f409460cb4d uv_cond_wait (libuv.so.1)
                #2  0x00007f40945fbbed worker (libuv.so.1)
                #3  0x00007f409480e4e2 start_thread (libpthread.so.0)
                #4  0x00007f409473d643 __clone (libc.so.6)
                
                Stack trace of thread 8073:
                #0  0x00007f4094814d45 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f409460cb4d uv_cond_wait (libuv.so.1)
                #2  0x00007f409550c7f3 _ZN4node12_GLOBAL__N_1L20PlatformWorkerThreadEPv (libnode.so.72)
                #3  0x00007f409480e4e2 start_thread (libpthread.so.0)
                #4  0x00007f409473d643 __clone (libc.so.6)
                
                Stack trace of thread 8071:
                #0  0x00007f4094814d45 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f409460cb4d uv_cond_wait (libuv.so.1)
                #2  0x00007f409550c7f3 _ZN4node12_GLOBAL__N_1L20PlatformWorkerThreadEPv (libnode.so.72)
                #3  0x00007f409480e4e2 start_thread (libpthread.so.0)
                #4  0x00007f409473d643 __clone (libc.so.6)

GNU gdb (GDB) Fedora 8.3.50.20190824-24.fc31
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/node...
Reading symbols from .gnu_debugdata for /usr/bin/node...
(No debugging symbols found in .gnu_debugdata for /usr/bin/node)
[New LWP 8068]
[New LWP 8069]
[New LWP 8075]
[New LWP 8072]
[New LWP 8070]
[New LWP 8080]
[New LWP 8079]
[New LWP 8078]
[New LWP 8077]
[New LWP 8073]
[New LWP 8071]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/bin/node /home/ruslanosmanov/.config/coc/extensions/node_modules/coc-phpls'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007f4094678625 in raise () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x7f40940f3200 (LWP 8068))]
Missing separate debuginfos, use: dnf debuginfo-install nodejs-12.13.0-7.fc31.x86_64
(gdb) thread 
apply  find   name   
(gdb) thread 
apply  find   name   
(gdb) thread apply all bt

Thread 11 (Thread 0x7f40930dc700 (LWP 8071)):
#0  0x00007f4094814d45 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f409460cb4d in uv_cond_wait () from /lib64/libuv.so.1
#2  0x00007f409550c7f3 in node::(anonymous namespace)::PlatformWorkerThread(void*) () from /lib64/libnode.so.72
#3  0x00007f409480e4e2 in start_thread () from /lib64/libpthread.so.0
#4  0x00007f409473d643 in clone () from /lib64/libc.so.6

Thread 10 (Thread 0x7f40920da700 (LWP 8073)):
#0  0x00007f4094814d45 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f409460cb4d in uv_cond_wait () from /lib64/libuv.so.1
#2  0x00007f409550c7f3 in node::(anonymous namespace)::PlatformWorkerThread(void*) () from /lib64/libnode.so.72
#3  0x00007f409480e4e2 in start_thread () from /lib64/libpthread.so.0
#4  0x00007f409473d643 in clone () from /lib64/libc.so.6

Thread 9 (Thread 0x7f40918d9700 (LWP 8077)):
#0  0x00007f4094814d45 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f409460cb4d in uv_cond_wait () from /lib64/libuv.so.1
#2  0x00007f40945fbbed in worker () from /lib64/libuv.so.1
#3  0x00007f409480e4e2 in start_thread () from /lib64/libpthread.so.0
#4  0x00007f409473d643 in clone () from /lib64/libc.so.6

Thread 8 (Thread 0x7f40910d8700 (LWP 8078)):
#0  0x00007f4094814d45 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f409460cb4d in uv_cond_wait () from /lib64/libuv.so.1
#2  0x00007f40945fbbed in worker () from /lib64/libuv.so.1
#3  0x00007f409480e4e2 in start_thread () from /lib64/libpthread.so.0
#4  0x00007f409473d643 in clone () from /lib64/libc.so.6

Thread 7 (Thread 0x7f40908d7700 (LWP 8079)):
#0  0x00007f4094814d45 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f409460cb4d in uv_cond_wait () from /lib64/libuv.so.1
#2  0x00007f40945fbbed in worker () from /lib64/libuv.so.1
#3  0x00007f409480e4e2 in start_thread () from /lib64/libpthread.so.0
#4  0x00007f409473d643 in clone () from /lib64/libc.so.6

Thread 6 (Thread 0x7f407bfff700 (LWP 8080)):
#0  0x00007f4094814d45 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f409460cb4d in uv_cond_wait () from /lib64/libuv.so.1
#2  0x00007f40945fbbed in worker () from /lib64/libuv.so.1
#3  0x00007f409480e4e2 in start_thread () from /lib64/libpthread.so.0
#4  0x00007f409473d643 in clone () from /lib64/libc.so.6

Thread 5 (Thread 0x7f40938dd700 (LWP 8070)):
#0  0x00007f4094814d45 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f409460cb4d in uv_cond_wait () from /lib64/libuv.so.1
#2  0x00007f409550c7f3 in node::(anonymous namespace)::PlatformWorkerThread(void*) () from /lib64/libnode.so.72
#3  0x00007f409480e4e2 in start_thread () from /lib64/libpthread.so.0
#4  0x00007f409473d643 in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x7f40928db700 (LWP 8072)):
#0  0x00007f4094814d45 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00007f409460cb4d in uv_cond_wait () from /lib64/libuv.so.1
#2  0x00007f409550c7f3 in node::(anonymous namespace)::PlatformWorkerThread(void*) () from /lib64/libnode.so.72
--Type <RET> for more, q to quit, c to continue without paging--
#3  0x00007f409480e4e2 in start_thread () from /lib64/libpthread.so.0
#4  0x00007f409473d643 in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x7f4098d3e700 (LWP 8075)):
#0  0x00007f40948178f4 in do_futex_wait.constprop () from /lib64/libpthread.so.0
#1  0x00007f40948179e8 in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0
#2  0x00007f409460cbd2 in uv_sem_wait () from /lib64/libuv.so.1
#3  0x00007f409556fba4 in node::inspector::(anonymous namespace)::StartIoThreadMain(void*) () from /lib64/libnode.so.72
#4  0x00007f409480e4e2 in start_thread () from /lib64/libpthread.so.0
#5  0x00007f409473d643 in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7f40940de700 (LWP 8069)):
#0  0x00007f409473d97e in epoll_wait () from /lib64/libc.so.6
#1  0x00007f409460fef9 in uv.io_poll () from /lib64/libuv.so.1
#2  0x00007f40945ffe7c in uv_run () from /lib64/libuv.so.1
#3  0x00007f4095510a9d in node::WorkerThreadsTaskRunner::DelayedTaskScheduler::Start()::{lambda(void*)#1}::_FUN(void*) () from /lib64/libnode.so.72
#4  0x00007f409480e4e2 in start_thread () from /lib64/libpthread.so.0
#5  0x00007f409473d643 in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f40940f3200 (LWP 8068)):
#0  0x00007f4094678625 in raise () from /lib64/libc.so.6
#1  0x00007f40946618d9 in abort () from /lib64/libc.so.6
#2  0x00007f409548ea19 in node::Abort() () from /lib64/libnode.so.72
#3  0x00007f4095490915 in node::OnFatalError(char const*, char const*) () from /lib64/libnode.so.72
#4  0x00007f40957e09aa in v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) () from /lib64/libnode.so.72
#5  0x00007f40957e0c32 in v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) () from /lib64/libnode.so.72
#6  0x00007f4095968419 in v8::internal::Heap::FatalProcessOutOfMemory(char const*) () from /lib64/libnode.so.72
#7  0x00007f409597df17 in v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) () from /lib64/libnode.so.72
#8  0x00007f409597ec8d in v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) () from /lib64/libnode.so.72
#9  0x00007f409598107c in v8::internal::Heap::AllocateRawWithLightRetry(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) () from /lib64/libnode.so.72
#10 0x00007f40959813a5 in v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) () from /lib64/libnode.so.72
#11 0x00007f409594809d in v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType) () from /lib64/libnode.so.72
#12 0x00007f4095c6852d in v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) () from /lib64/libnode.so.72
#13 0x00007f409630c299 in Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit () from /lib64/libnode.so.72
#14 0x00000483b18d0926 in ?? ()
#15 0x0000000000000000 in ?? ()
(gdb) 

Obviously, the problem is that the memory consumed by the node process exceeds some limit. I guess, the heap size limit. According the the official news, this kind of issue should've been handled automatically as long as I have sufficient RAM. I have 16G of total RAM which seems to be quite enough for Firefox with a few tabs, Vim, and intelephense. I'll try to set the heap size limit explicitly... somehow.

[rosmanov]

Increased heap size up to 8G via environment:

export NODE_OPTIONS=--max_old_space_size=8192

So far no crashes :-)