Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Hi, On Wed, Mar 01, 2023 at 02:41:05PM +0100, Jérémy Lal wrote: > For now I'm unlucky with the porterbox, because /var/run/schroot > disappeared yesterday. I can confirm that the issue isn't reproducible with V8_DEFAULT_STACK_SIZE_KB set to 984. Built and tested on a Macbook M1. (sid-arm64)ema@sarzana:~/debian/dygraphs-2.2.1 $ babeljs --config-file $PWD/babel.config.json --compact false --source-maps inline -d tests5 auto_tests Successfully compiled 59 files with Babel (994ms).
Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Le mer. 1 mars 2023 à 14:39, James Addison a écrit : > If reproducible: would this bug be a good candidate for upload of a > fix to 'experimental' so that it can be alpha-tested by others? > Sure. For now I'm unlucky with the porterbox, because /var/run/schroot disappeared yesterday. Notified debian-admin. Jérémy
Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
If reproducible: would this bug be a good candidate for upload of a fix to 'experimental' so that it can be alpha-tested by others? On Wed, 1 Mar 2023 at 02:55, Jérémy Lal wrote: > > > > Le mer. 1 mars 2023 à 02:30, Thorsten Glaser a écrit : >> >> Jérémy Lal dixit: >> >> >I can build nodejs on amhdal.debian.org if you're not comfortable with that. >> >> The problem with the DSA porterboxen is that you cannot install your own >> built packages in the chroot to use them there… unless there’s a >> solution not yet known to me? > > > Indeed, but the binary can be run from build dir, so I just need to try and > reproduce the bug from there. >
Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Le mer. 1 mars 2023 à 02:30, Thorsten Glaser a écrit : > Jérémy Lal dixit: > > >I can build nodejs on amhdal.debian.org if you're not comfortable with > that. > > The problem with the DSA porterboxen is that you cannot install your own > built packages in the chroot to use them there… unless there’s a > solution not yet known to me? > Indeed, but the binary can be run from build dir, so I just need to try and reproduce the bug from there.
Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Jérémy Lal dixit: >I can build nodejs on amhdal.debian.org if you're not comfortable with that. The problem with the DSA porterboxen is that you cannot install your own built packages in the chroot to use them there… unless there’s a solution not yet known to me? bye, //mirabilos -- “ah that reminds me, thanks for the stellar entertainment that you and certain other people provide on the Debian mailing lists │ sole reason I subscribed to them (I'm not using Debian anywhere) is the entertainment factor │ Debian does not strike me as a place for good humour, much less German admin-style humour”
Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
That'd be great, thank you - my local (emulated) aarch64 build of nodejs is proving to be much more time consuming than I expected. On Tue, 28 Feb 2023 at 23:21, Jérémy Lal wrote: > > > > Le mar. 28 févr. 2023 à 19:06, James Addison a écrit : >> >> On Tue, Feb 28, 2023, 17:55 Thorsten Glaser wrote: >>> >>> Can you test it? I don’t have the bandwidth for that right now… >> >> >> Should be able to, yep - I seem to remember seeing some repro instructions >> from you on the GitHub thread and will give those a try in an emulator/vm. > > > I can build nodejs on amhdal.debian.org if you're not comfortable with that. > >> -- >> Pkg-javascript-devel mailing list >> pkg-javascript-de...@alioth-lists.debian.net >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Le mar. 28 févr. 2023 à 19:06, James Addison a écrit : > On Tue, Feb 28, 2023, 17:55 Thorsten Glaser wrote: > >> Can you test it? I don’t have the bandwidth for that right now… > > > Should be able to, yep - I seem to remember seeing some repro instructions > from you on the GitHub thread and will give those a try in an emulator/vm. > I can build nodejs on amhdal.debian.org if you're not comfortable with that. -- > Pkg-javascript-devel mailing list > pkg-javascript-de...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel >
Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Le mar. 28 févr. 2023 à 00:33, James Addison a écrit : > Package: nodejs > Followup-For: Bug #1030284 > X-Debbugs-Cc: t...@debian.org, > reply+aagshfqluldiwi3obwdg6lgb7if7fevbnhheauz...@reply.github.com > > mirabilos gesagt: > > > We know the default ulimits for users in Debian, and they are higher > > than the 1 MiB assumed by v8, by quite some factor, so this won’t break > > things which are not currently broken (by that exception). This will do > > for the release I think. > > Relaying my understanding of this, so far: > > An increase in the V8 stack size should not cause earlier-process-exits > for any > processes that previously ran on Debian systems where the > architecture-default-or-greater stack size is configured[1]. > > In other words: the same-number-or-greater of JavaScript processes should > continue to run on any given Debian system where the configured stack size > is > greater-than-or-equal to the architecture's default, after the V8 stack > size > limit is increased. > > And we expect that it should repair a failing reproducible build test for > at > least one Debian package on arm64. Thanks, I'll welcome any patch to start with. My plan is to rebuild / retest reverse deps before hard freeze.
Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Le mer. 15 févr. 2023 à 14:39, Thorsten Glaser a écrit :
> Hi James,
>
> (you might wish to Cc <${bugnumber}-submit...@bugs.debian.org> so they
> actually get the reply…)
>
> >Are you able to determine whether
> https://github.com/nodejs/node/issues/41163
> >(and/or any of the guidance within that thread) seems relevant to this
> bug?
>
> It appears so. I commented there, thank you for finding that link.
>
> I guess there is even a… quick patch… to make from this. I admit
> I’m very confused by that statement:
>
> “if you set it too high, you risk crashes”
>
> That can’t be right.
>
> Searching through the nodejs source for where this stack size is
> set, I see multiple time bombs for all architectures.
>
> deps/v8/src/common/globals.h does set the default stack size to
> 864/984 KiB in order to achieve an about 1 MiB stack for JS plus
> C++ parts combined.
>
> I wonder if this shouldn’t be getrlimit(RLIMIT_STACK) - overhead,
> and then define the per-architecture overhead in a suitable way.
>
> That lower 1 MiB total limit seems to be for Windows. The lower
> arm64 limit is caused by “allocating MacroAssembler takes 120 [KiB]”
> but the total could still be raised I think… at least on unixoid
> platforms other than WebView-on-Android. Since the location of these
> defaults is in v8, it also applies for browsers and whatnot, but
> nodejs could indeed inspect the current ulimit and set a better
> default for at least nōn-Windows systems.
>
> I’m not, unfortunately, in the position to provide a quick patch,
> being a C developer, not CFrustFrust, and all that. I think that
> InitializeNodeWithArgs in src/node.cc, which already has a call
> to V8::SetFlagsFromString(NODE_V8_OPTIONS, …), is the likely place
> for adding code (suitably platform-ifdef’d) that does:
>
> - get the ulimit
> - subtract some arch-specific overhead target
> - check that that’s positive (or >= V8_DEFAULT_STACK_SIZE_KB even,
> that might be a good idea)
> - if so, pass this as synthetic --stack-size (or --stack_size?) to
> v8, overriding its default but allowing for a later option given
> by the user’s argv[] to override _that_, again
>
> Might need to adjust some tests, too :~
While waiting for the proper fix you describe, I propose to set higher
constants
for V8_DEFAULT_STACK_SIZE_KB - especially for arm64.
Jérémy
