Followup-For: Bug #1030284
I decline to participate further with this bugreport, although others are
welcome to pick up from the patches I've submitted (please don't merge them
as-is; modify them to apply corrections).
James Addison dixit:
>AssertionError [ERR_ASSERTION]: The input did not match the regular
> expression /RangeError: Maximum call stack size exceeded/. Input:
>
>'Segmentation fault\n'
You removed the subtraction of V8_STACK_RESERVE when mutilating
my patch; this may be related (if
Followup-For: Bug #1030284
X-Debbugs-Cc: t...@mirbsd.de
It does seem to (continue to) function, at least on x86:
~/dygraphs-2.2.0$ NODE_PATH=/usr/share/nodejs
../nodejs-18.13.0+dfsg1/out/Release/node /usr/bin/babeljs --config-file
$PWD/babel.config.json --compact false --source-maps inline
Followup-For: Bug #1030284
X-Debbugs-Cc: t...@mirbsd.de
Hmm.. although the build itself succeeded, there was a unit test failure that
appears related to the change:
not ok 3213 sequential/test-fs-stat-sync-overflow
---
duration_ms: 1.111
severity: fail
exitcode: 1
stack: |-
Followup-For: Bug #1030284
X-Debbugs-Cc: t...@mirbsd.de
Thanks, Thorsten. I'm currently rebuilding (on x86) from the attached patch,
adapted from yours.
* prefers a one-time repeat division over the clever-but-fragile div-assign
* removes the upperbound check because integer greater-than
James Addison dixit:
>... to add something like this:
Ouch, by going via a string?! I wouldn’t have thought of that…
> if (!(flags & ProcessInitializationFlags::kNoAdjustResourceLimits)) {
>struct rlimit lim;
>if (getrlimit(RLIMIT_STACK, ) == 0) {
> char stackSize[32];
32 is
On Sat, 13 May 2023 at 12:15, James Addison wrote:
>
> On Sat, 13 May 2023 at 11:14, James Addison wrote:
> >
> > On Sat, 13 May 2023 at 02:18, Thorsten Glaser wrote:
> > >
> > > James Addison dixit:
> > >
> > > >I'm going to stay involved with this thread, but I think that it is
> > > >upon
On Sat, 13 May 2023 at 11:14, James Addison wrote:
>
> On Sat, 13 May 2023 at 02:18, Thorsten Glaser wrote:
> >
> > James Addison dixit:
> >
> > >I'm going to stay involved with this thread, but I think that it is
> > >upon you to develop or provide further guidance towards a patch if
> > >it's
On Sat, 13 May 2023 at 02:18, Thorsten Glaser wrote:
>
> James Addison dixit:
>
> >I'm going to stay involved with this thread, but I think that it is
> >upon you to develop or provide further guidance towards a patch if
> >it's something you'd like to have implemented, Thorsten.
>
> I actually
James Addison dixit:
>I'm going to stay involved with this thread, but I think that it is
>upon you to develop or provide further guidance towards a patch if
>it's something you'd like to have implemented, Thorsten.
I actually have looked into that but I don’t understand the nodejs
and v8 source
On Fri, 12 May 2023 at 23:23, James Addison wrote:
>
> On Fri, 12 May 2023 at 16:54, Thorsten Glaser wrote:
> >
> > Yes, but given the usual ulimit, the new limit would be 4+ times
> > the old one, much much harder to reach.
>
> That does sound promising.
>
> I've followed up on this discussion
On Fri, 12 May 2023 at 16:54, Thorsten Glaser wrote:
>
> Yes, but given the usual ulimit, the new limit would be 4+ times
> the old one, much much harder to reach.
That does sound promising.
I've followed up on this discussion with the relevant upstream NodeJS
thread, and beyond there to the
James Addison dixit:
>So: a fix here won't achieve stack capacity equality across
No. The fix you proposed won’t achieve that but others would
improve the situation much more, so that equality across arches
won’t need to matter any more.
>Or, to put it another way: applying an increase (either
On Thu, 11 May 2023 at 23:54, Thorsten Glaser wrote:
>
> James Addison dixit:
>
> >On Thu, 11 May 2023 at 02:43, Andres Salomon 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
James Addison dixit:
>On Thu, 11 May 2023 at 02:43, Andres Salomon 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
>>
On Thu, 11 May 2023 at 02:43, Andres Salomon wrote:
>
> On Sat, 11 Mar 2023 11:04:15 + James Addison
> 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
> >
On Sat, 11 Mar 2023 11:04:15 + James Addison
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:
James Addison dixit:
>Based on what I've learned about this bug, I believe that architecture-specific
>behaviour related to stack sizes is inherent in the V8 library vendored by
>upstream NodeJS.
Yes, but the v8 library’s defaults are targetting a browser, and one
whose uses are much wider, e.g.
Package: nodejs
Followup-For: Bug #1030284
X-Debbugs-Cc: t...@mirbsd.de
On Thu, 02 Feb 2023 01:56:10 +, Thorsten wrote:
> I consider this an architecture-specific release-critical bug. Maybe
> having a reproducer and access to a porterbox will allow a nodejs
> maintainer to track this down.
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
Package: nodejs
Followup-For: Bug #1030284
Echoing some notes and findings from the GitHub issue thread:
* https://crbug.com/405338 seems inaccessible to at least two people
* https://codereview.chromium.org/555943003 was initially proposed to resolve
that bug
*
Followup-For: Bug #1030284
There is one part of this patch that worries me, and it is the line:
> -//See issue crbug.com/405338
I'm not able to access that bug: neither anonymously nor when logged into my
gmail account. The comment would seem to indicate that it contains relevant
context
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.
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
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
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
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
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
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
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.
James Addison dixit:
>Hi - what do you both think of the attached patch, which brings the ARM stack
>size into line with almost all other architectures (= 984 KB)?
It might do the job unless arm64 for some reason uses more stack
elsewhere as well.
Can you test it? I don’t have the bandwidth for
Package: nodejs
Followup-For: Bug #1030284
X-Debbugs-Cc: t...@debian.org
> My plan is to rebuild / retest reverse deps before hard freeze.
That's a good plan.
Do you know whether any of those tests include cases that spin up large (as in:
may consume more than 50% of a system's memory) numbers
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
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
James Addison dixit:
>Maybe it's rare to propose 'do nothing' as a technical suggestion but I think
>it is worth considering here, since we are not the arbiters of Node.
It’s still a release-critical bug in Debian which impacts arm64 builders
including reproducible-builds. I would see this fixed
Package: nodejs
Followup-For: Bug #1030284
Control: forwarded -1 https://github.com/nodejs/node/issues/41163
Package: nodejs
Followup-For: Bug #1030284
On Wed, 15 Feb 2023 14:54:03 +0100, Jérémy wrote:
> While waiting for the proper fix you describe, I propose to set higher
> constants
> for V8_DEFAULT_STACK_SIZE_KB - especially for arm64.
That sounded good to me when I read it a week ago, but now I'm
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
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,
Package: nodejs
Followup-For: Bug #1030284
Hi Thorsten,
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?
If so, your repro example could be useful to help upstream/contributors to
develop
Package: nodejs
Version: 18.13.0+dfsg1-1
Severity: serious
Tags: upstream
Justification: breaks on release architecture
X-Debbugs-Cc: t...@mirbsd.de
Control: affects -1 src:dygraphs
During reproducible-builds testing, I found that one of my packages,
the one with nodejs used during build, worked
41 matches
Mail list logo
