On Thu, 11 May 2023 at 23:54, Thorsten Glaser <t...@debian.org> wrote: > > James Addison dixit: > > >On Thu, 11 May 2023 at 02:43, Andres Salomon <dilin...@queued.net> wrote: > > >> For ARM64, he says that raising the stack limit is not safe for v8 > >> *embedded inside WebView*, and therefore not appropriate for upstream > >> v8. But then he says it could/should be safe for v8 *embedded inside > >> NodeJS*. > >> > >> Based on that, I suggest patching Debian's NodeJS with the patch to > >> adjust armhf/arm64 stack limit size > > That would be a good thing (huh, wasn’t armhf good?), but… > > >I have a question: if we apply the patch and begin using the same > >constant stack size of 984kb on 32-bit ARM and 64-bit ARM as is > >defined for other architectures, then does NodeJS on those platforms > >begin supporting exactly the same stack frame capacity (maximum call > >depth for any given recursive function, for example) as a build of the > >same NodeJS source on x86 and amd64 respectively? > > … no, because both stack usage and other stuff on stack differ.
Ok, that's what I thought, but I'm not familiar with the details here. So: a fix here won't achieve stack capacity equality across architectures. (I say this because I think we should be clear about what the bugreport is about, and, where possible, the known limitations of fixes) Or, to put it another way: applying an increase (either static or dynamic, either ARM-specific or across all architectures) for stack size determination would move the problem, and another architecture would take the place of "architecture where RangeError can occur in code x that doesn't occur on other architectures". Do those statements seem true? (they make sense to me, but I also think it's possible that I've misunderstood something here) > Which is why I’d rather have the getrlimit-based one for nodejs. > That would give us twice to four times the limit. That makes sense, and I agree that dynamic stack-sizing could help (perhaps quite a lot on some systems). We'd need a patch to implement it, though - and based on their current policy, NodeJS upstream seem unlikely to accept it since they don't want to modify their vendored V8. But if it showed significant benefits then perhaps we could use that to contribute to further discussion with either/both of those projects.
