-
Notifications
You must be signed in to change notification settings - Fork 7
Description
I have experienced a RangeError with ssb-server like the one reported in %SIUZgmh71CWw/vQXB6lG+p1UZhxa3ClQC9oZDAxPZhg=.sha256
.
I increased my Node process's stack trace lines and extracted the following periodic part of the call stack:
at /home/cel/.local/lib/node_modules/ssb-server/node_modules/flumeview-hashtable/index.js:26:11
at next (/home/cel/.local/lib/node_modules/ssb-server/node_modules/flumeview-hashtable/hashtable.js:47:13)
at /home/cel/.local/lib/node_modules/ssb-server/node_modules/flumeview-hashtable/hashtable.js:52:20
at /home/cel/.local/lib/node_modules/ssb-server/node_modules/flumelog-offset/inject.js:93:9
at /home/cel/.local/lib/node_modules/ssb-server/node_modules/flumelog-offset/frame/recoverable.js:48:11
at /home/cel/.local/lib/node_modules/ssb-server/node_modules/aligned-block-file/blocks.js:75:11
at get (/home/cel/.local/lib/node_modules/ssb-server/node_modules/aligned-block-file/blocks.js:29:7)
at next (/home/cel/.local/lib/node_modules/ssb-server/node_modules/aligned-block-file/blocks.js:53:7)
at Object.read (/home/cel/.local/lib/node_modules/ssb-server/node_modules/aligned-block-file/blocks.js:78:7)
at next (/home/cel/.local/lib/node_modules/ssb-server/node_modules/flumelog-offset/frame/recoverable.js:47:16)
at /home/cel/.local/lib/node_modules/ssb-server/node_modules/flumelog-offset/frame/recoverable.js:43:11
at /home/cel/.local/lib/node_modules/ssb-server/node_modules/aligned-block-file/blocks.js:96:11
at get (/home/cel/.local/lib/node_modules/ssb-server/node_modules/aligned-block-file/blocks.js:29:7)
at Object.readUInt32BE (/home/cel/.local/lib/node_modules/ssb-server/node_modules/aligned-block-file/blocks.js:93:9)
at /home/cel/.local/lib/node_modules/ssb-server/node_modules/flumelog-offset/frame/recoverable.js:41:16
at /home/cel/.local/lib/node_modules/ssb-server/node_modules/aligned-block-file/blocks.js:96:11
at get (/home/cel/.local/lib/node_modules/ssb-server/node_modules/aligned-block-file/blocks.js:29:7)
at Object.readUInt32BE (/home/cel/.local/lib/node_modules/ssb-server/node_modules/aligned-block-file/blocks.js:93:9)
at Object.getMeta (/home/cel/.local/lib/node_modules/ssb-server/node_modules/flumelog-offset/frame/recoverable.js:31:12)
at Object.get (/home/cel/.local/lib/node_modules/ssb-server/node_modules/flumelog-offset/inject.js:85:13)
at Object.get (/home/cel/.local/lib/node_modules/ssb-server/node_modules/flumedb/index.js:31:10)
at Object.get (/home/cel/.local/lib/node_modules/ssb-server/node_modules/flumedb/index.js:63:16)
at /home/cel/.local/lib/node_modules/ssb-server/node_modules/flumeview-hashtable/index.js:26:11
In this code path, there are two recursive asynchronous parts: in flumeview-hashtable/hashtable.js and in aligned-block-file/blocks.js. That should be okay, since the methods they call are asynchronous. But the present code path actually executes synchronously. The caching get method in aligned-block-file/blocks.js returns the callback synchronously if the value is cached. I think that is the only place in the stack where an asynchronous function necessarily calls back synchronously, and so is the best place to change to limit the stack growth. The straightforward way is to wrap the callback in a setImmediate
or process.nextTick
closure.