On Thu, 11 May 2023 at 02:43, Andres Salomon <dilin...@queued.net> wrote:
>
> On Sat, 11 Mar 2023 11:04:15 +0000 James Addison <j...@jp-hosting.net>
> wrote:
>  > Package: nodejs
>  > Followup-For: Bug #1030284
>  > X-Debbugs-Cc: t...@debian.org
>  >
>  > Guidance received from the V8 project (a vendored dependency in the
> upstream
>  > NodeJS codebase) on the v8-dev mailing list is, in
> summary/interpretation:
>  >
>  >   * It is not yet safe to increase the stack size limit on ARM64
> systems.
> [...]
>  > Sidenotes:
>  >
>  > A patch for 32-bit architectures could apparently be acceptable,
> although may
>  > be best offered to NodeJS rather than V8.  For what it's worth:
> NodeJS seems
>  > to have a policy of not accepting patches to their vendored
> dependencies.
>  >
>
> In reading Jakob's response
> (https://groups.google.com/g/v8-dev/c/7ZI3vxtabcU/m/c9qvHkOBBAAJ), I'm
> interpreting it slightly differently-
>
> He says that raising the stack limit *is* safe for 32-bit ARM, even
> inside of the V8 upstream source tree.
>
> 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 to 984kb. With the caveat that the
> javascript code that is triggering this bug should really be fixed to
> not be so stack-intensive, of course. Perhaps this bug cloned at a
> lower severity, filed against those packages that this bug is affecting?
>
> (As chromium maintainer, which also embeds v8, I haven't heard of any
> issues and hadn't planned on touching stacks limits. It sure would be
> nice to have just one copy of V8 in the archive, though..)

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?

Reply via email to