Le mar. 21 sept. 2021 à 08:46, Jérémy Lal a écrit :
>
>
> Le mar. 21 sept. 2021 à 08:34, Ondrej Zary a écrit :
>
>> On Tuesday 21 September 2021, Jérémy Lal wrote:
>>
>> > Libuv1 1.34.2 - same version as the one in nodejs/deps/uv/ - is in
>> > buster-backports.
>> > It would be nice to try build
Le mar. 21 sept. 2021 à 08:58, Ondrej Zary a écrit :
>
> On Tuesday 21 September 2021, Bastien ROUCARIES wrote:
> > Le mar. 21 sept. 2021 à 07:55, Ondrej Zary a écrit :
> > >
> > > On Monday 20 September 2021, Bastien Roucariès wrote:
> > > > Le lundi 20 septembre 2021, 19:32:52 UTC Bastien ROUCA
On Tuesday 21 September 2021, Bastien ROUCARIES wrote:
> Le mar. 21 sept. 2021 à 07:55, Ondrej Zary a écrit :
> >
> > On Monday 20 September 2021, Bastien Roucariès wrote:
> > > Le lundi 20 septembre 2021, 19:32:52 UTC Bastien ROUCARIES a écrit :
> > > Could you try one by one the following untest
Le mar. 21 sept. 2021 à 07:55, Ondrej Zary a écrit :
>
> On Monday 20 September 2021, Bastien Roucariès wrote:
> > Le lundi 20 septembre 2021, 19:32:52 UTC Bastien ROUCARIES a écrit :
> > Could you try one by one the following untested patch. Please compile and
> > run
> > the testsuite.
>
> The
On Monday 20 September 2021, Bastien Roucariès wrote:
> Le lundi 20 septembre 2021, 19:32:52 UTC Bastien ROUCARIES a écrit :
> Could you try one by one the following untested patch. Please compile and run
> the testsuite.
The first one fails to compile:
In file included from ../src/util-inl.h:28,
Le mar. 21 sept. 2021 à 08:34, Ondrej Zary a écrit :
> On Tuesday 21 September 2021, Jérémy Lal wrote:
>
> > Libuv1 1.34.2 - same version as the one in nodejs/deps/uv/ - is in
> > buster-backports.
> > It would be nice to try building against that version.
> > Some nodejs tests might fail (patche
On Tuesday 21 September 2021, Jérémy Lal wrote:
> Le lun. 20 sept. 2021 à 22:30, Ondrej Zary a écrit :
>
> > On Monday 20 September 2021 21:32:52 Bastien ROUCARIES wrote:
> > > Could you try first to apply
> > https://github.com/nodejs/node/commit/c60780ff52
> > >
> > > And see if the reject are
Le lun. 20 sept. 2021 à 22:30, Ondrej Zary a écrit :
> On Monday 20 September 2021 21:32:52 Bastien ROUCARIES wrote:
> > Could you try first to apply
> https://github.com/nodejs/node/commit/c60780ff52
> >
> > And see if the reject are bad ?
>
> Lots of failed hunks, I'll never get this to compile
On Monday 20 September 2021 21:32:52 Bastien ROUCARIES wrote:
> Could you try first to apply https://github.com/nodejs/node/commit/c60780ff52
>
> And see if the reject are bad ?
Lots of failed hunks, I'll never get this to compile:
$ patch -p1 <../node.git/custom-smart-pointers.patch
patching fi
Could you try first to apply https://github.com/nodejs/node/commit/c60780ff52
And see if the reject are bad ?
Bastien
Le lun. 20 sept. 2021 à 19:15, Ondrej Zary a écrit :
>
>
>
> On Monday 20 September 2021 19:31:56 Bastien ROUCARIES wrote:
> > Le lun. 20 sept. 2021 à 17:28, Jérémy Lal a écrit
On Monday 20 September 2021 19:31:56 Bastien ROUCARIES wrote:
> Le lun. 20 sept. 2021 à 17:28, Jérémy Lal a écrit :
> >
> >
> >
> > Le lun. 20 sept. 2021 à 19:15, Ondrej Zary a écrit :
> > >
> > > On Monday 20 September 2021 16:56:18 Bastien ROUCARIES wrote:
> > > > Le lun. 20 sept. 2021 à 14:
Le lun. 20 sept. 2021 à 19:32, Bastien ROUCARIES <
roucaries.bast...@gmail.com> a écrit :
> Le lun. 20 sept. 2021 à 17:28, Jérémy Lal a écrit :
> >
> >
> >
> > Le lun. 20 sept. 2021 à 19:15, Ondrej Zary a écrit :
> > >
> > > On Monday 20 September 2021 16:56:18 Bastien ROUCARIES wrote:
> > > > L
Le lun. 20 sept. 2021 à 17:28, Jérémy Lal a écrit :
>
>
>
> Le lun. 20 sept. 2021 à 19:15, Ondrej Zary a écrit :
> >
> > On Monday 20 September 2021 16:56:18 Bastien ROUCARIES wrote:
> > > Le lun. 20 sept. 2021 à 14:24, Ondrej Zary a écrit :
> > > >
> > > > On Monday 20 September 2021, Bastien R
Le lun. 20 sept. 2021 à 19:15, Ondrej Zary a écrit :
>
> On Monday 20 September 2021 16:56:18 Bastien ROUCARIES wrote:
> > Le lun. 20 sept. 2021 à 14:24, Ondrej Zary a écrit :
> > >
> > > On Monday 20 September 2021, Bastien ROUCARIES wrote:
> > > > Could you try to apply
> > > >
> > > >
https://
Le lun. 20 sept. 2021 à 17:15, Ondrej Zary a écrit :
>
> On Monday 20 September 2021 16:56:18 Bastien ROUCARIES wrote:
> > Le lun. 20 sept. 2021 à 14:24, Ondrej Zary a écrit :
> > >
> > > On Monday 20 September 2021, Bastien ROUCARIES wrote:
> > > > Could you try to apply
> > > >
> > > > https://
On Monday 20 September 2021 16:56:18 Bastien ROUCARIES wrote:
> Le lun. 20 sept. 2021 à 14:24, Ondrej Zary a écrit :
> >
> > On Monday 20 September 2021, Bastien ROUCARIES wrote:
> > > Could you try to apply
> > >
> > > https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4
Le lun. 20 sept. 2021 à 15:00, Bastien ROUCARIES
a écrit :
>
> Le lun. 20 sept. 2021 à 14:24, Ondrej Zary a écrit :
> >
> > On Monday 20 September 2021, Bastien ROUCARIES wrote:
> > > Could you try to apply
> > >
> > > https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4
Le lun. 20 sept. 2021 à 14:24, Ondrej Zary a écrit :
>
> On Monday 20 September 2021, Bastien ROUCARIES wrote:
> > Could you try to apply
> >
> > https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4
> >
> > I think it describe that you see
>
> Does not apply, unfortunatel
On Monday 20 September 2021, Bastien ROUCARIES wrote:
> Could you try to apply
>
> https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4
>
> I think it describe that you see
Does not apply, unfortunately. There's no node_dir.cc file and also no
BaseObjectPtr definition.
Could you try to apply
https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4
I think it describe that you see
Bastien
Le lun. 20 sept. 2021 à 12:51, Ondrej Zary a écrit :
>
> > Ok are you on IRC ? I am as rouca on #debian-js channel
>
> No, I'm not.
>
> > Install the d
> Ok are you on IRC ? I am as rouca on #debian-js channel
No, I'm not.
> Install the debug symbols of nodejs and libuv (if available) and try
> to run valgrind with --smc-check=all --read-var-info=yes
> --track-origins=yes
# runuser -u gitlab -- sh -c 'valgrind --smc-check=all --read-var-info=ye
Ok are you on IRC ? I am as rouca on #debian-js channel
Install the debug symbols of nodejs and libuv (if available) and try
to run valgrind with --smc-check=all --read-var-info=yes
--track-origins=yes
Bastien
Le lun. 20 sept. 2021 à 11:57, Ondrej Zary a écrit :
>
> > And try to rebuild the w
> And try to rebuild the whole libuv and nodejs with -fstack-protector-all
Does not print anything other than Segmentation fault.
--
Ondrej Zary
> add --track-origins=yes to valgrind
Does not seem to change anything:
# runuser -u gitlab -- sh -c 'valgrind --trace-children=yes --track-origins=yes
yarnpkg install'
==6122== Memcheck, a memory error detector
==6122== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==6122== Usi
On Monday 20 September 2021, Bastien ROUCARIES wrote:
> Could you try to build both libuv and node with -fsanitize=null it is
> likely a null dereference so catch it
It does not seem to work correctly:
runuser -u gitlab -- sh -c 'yarnpkg install'
../deps/v8/src/date.cc:44:20: runtime error: member
Le lun. 20 sept. 2021 à 10:39, Ondrej Zary a écrit :
>
> > Ok now try to run the whole thing against valgrind...
> Seems that valgrind does not work with asan:
>
> $ LD_PRELOAD=/usr/lib/i386-linux-gnu/libasan.so.5.0.0 valgrind yarnpkg install
> ==752== Memcheck, a memory error detector
> ==752== C
> Ok now try to run the whole thing against valgrind...
Seems that valgrind does not work with asan:
$ LD_PRELOAD=/usr/lib/i386-linux-gnu/libasan.so.5.0.0 valgrind yarnpkg install
==752== Memcheck, a memory error detector
==752== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==75
Le lun. 20 sept. 2021 à 10:20, Bastien ROUCARIES
a écrit :
>
> Le lun. 20 sept. 2021 à 10:15, Ondrej Zary a écrit :
> >
> > libuv libuv1:i386 1.24.1-1+deb10u1 with -fsanitize=address,undefined:
> >
> > yarn install v1.13.0
> > [1/5] Validating package.json...
> > [2/5] Resolving packages...
> > [
Le lun. 20 sept. 2021 à 10:15, Ondrej Zary a écrit :
>
> libuv libuv1:i386 1.24.1-1+deb10u1 with -fsanitize=address,undefined:
>
> yarn install v1.13.0
> [1/5] Validating package.json...
> [2/5] Resolving packages...
> [3/5] Fetching packages...
> [-
libuv libuv1:i386 1.24.1-1+deb10u1 with -fsanitize=address,undefined:
yarn install v1.13.0
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
[--
Le lun. 20 sept. 2021 à 12:02, Ondrej Zary a écrit :
> I'm unable to compile node with -fsanitize=address,undefined. Seems that
> compiler hits 32-bit memory space limit:
> cc1plus: out of memory allocating 65536 bytes after a total of 3356393472
> bytes
>
Libuv only will be Nice
Node is not cro
I'm unable to compile node with -fsanitize=address,undefined. Seems that
compiler hits 32-bit memory space limit:
cc1plus: out of memory allocating 65536 bytes after a total of 3356393472 bytes
--
Ondrej Zary
Le lun. 20 sept. 2021 à 08:02, Ondrej Zary a écrit :
>
> Rebuilt Debian libuv1 1.24.1 with -fno-stack-protector - still segfaults.
> Rebuilt Debian libuv1 1.42.0 (from unstable) in Buster - still segfaults.
Please rebuild both nodejs and libuv with asan (adresse sanitizer)
After, I think it i
Rebuilt Debian libuv1 1.24.1 with -fno-stack-protector - still segfaults.
Rebuilt Debian libuv1 1.42.0 (from unstable) in Buster - still segfaults.
--
Ondrej Zary
Le dim. 19 sept. 2021 à 21:57, Bastien ROUCARIES
a écrit :
>
> try to pass
> -fstack-protector-strong to the local version as cflags
>
> If it fail upstream does not take in acount stack protector
>
> Le dim. 19 sept. 2021 à 21:45, Bastien ROUCARIES
> a écrit :
> >
> > Le dim. 19 sept. 2021 à 21
try to pass
-fstack-protector-strong to the local version as cflags
If it fail upstream does not take in acount stack protector
Le dim. 19 sept. 2021 à 21:45, Bastien ROUCARIES
a écrit :
>
> Le dim. 19 sept. 2021 à 21:39, Bastien ROUCARIES
> a écrit :
> >
> > Le dim. 19 sept. 2021 à 21:36, Ond
Le dim. 19 sept. 2021 à 21:39, Bastien ROUCARIES
a écrit :
>
> Le dim. 19 sept. 2021 à 21:36, Ondrej Zary a écrit :
> >
> > I've reinstalled nodejs and libnode64 back to original Buster
> > 10.24.0~dfsg-1~deb10u1 and upgraded libuv1 to
> > libuv1_1.34.2-1~bpo9+1_i386.deb from http://snapshot.de
Le dim. 19 sept. 2021 à 21:36, Ondrej Zary a écrit :
>
> I've reinstalled nodejs and libnode64 back to original Buster
> 10.24.0~dfsg-1~deb10u1 and upgraded libuv1 to libuv1_1.34.2-1~bpo9+1_i386.deb
> from http://snapshot.debian.org
>
> It still segfaults!
>
> So it seems that the problem is not
I've reinstalled nodejs and libnode64 back to original Buster
10.24.0~dfsg-1~deb10u1 and upgraded libuv1 to libuv1_1.34.2-1~bpo9+1_i386.deb
from http://snapshot.debian.org
It still segfaults!
So it seems that the problem is not libuv version but its linking (included in
node or external). Or c
Le dim. 19 sept. 2021 à 21:25, Bastien ROUCARIES
a écrit :
>
> Le dim. 19 sept. 2021 à 21:15, Ondrej Zary a écrit :
> >
> > Added back --shared-zlib: works.
> > Added back also --shared-cares: works.
> >
> > So you're right: --shared-libuv is the problem.
> > Upstream seems to include libuv 1.34.
Le dim. 19 sept. 2021 à 21:15, Ondrej Zary a écrit :
>
> Added back --shared-zlib: works.
> Added back also --shared-cares: works.
>
> So you're right: --shared-libuv is the problem.
> Upstream seems to include libuv 1.34.2.
> Buster has 1.24.1-1.
Do you have valgrind ?
If so and if it work (tes
Added back --shared-zlib: works.
Added back also --shared-cares: works.
So you're right: --shared-libuv is the problem.
Upstream seems to include libuv 1.34.2.
Buster has 1.24.1-1.
--
Ondrej Zary
Le dim. 19 sept. 2021 à 20:21, Ondrej Zary a écrit :
>
> On Sunday 19 September 2021 20:13:47 Bastien ROUCARIES wrote:
> > Hi,
> >
> > So you work on oldstable.
> >
> > Could you check for stable/testing/unstable/experimental ? And mark
> > the bug with found /not found.
>
> Unfortunately I can't.
On Sunday 19 September 2021 20:13:47 Bastien ROUCARIES wrote:
> Hi,
>
> So you work on oldstable.
>
> Could you check for stable/testing/unstable/experimental ? And mark
> the bug with found /not found.
Unfortunately I can't. I'm trying to get gitlab 11.11.8+dfsg-1+fto10+2 to work.
Then I can u
Le dim. 19 sept. 2021 à 19:37, Jérémy Lal a écrit :
>
>
>
> Le dim. 19 sept. 2021 à 20:18, Bastien ROUCARIES
> a écrit :
>>
>> Hi,
>>
>> So you work on oldstable.
>>
>> Could you check for stable/testing/unstable/experimental ? And mark
>> the bug with found /not found.
>>
>
> Interestingly, the
Le dim. 19 sept. 2021 à 20:18, Bastien ROUCARIES <
roucaries.bast...@gmail.com> a écrit :
> Hi,
>
> So you work on oldstable.
>
> Could you check for stable/testing/unstable/experimental ? And mark
> the bug with found /not found.
>
>
Interestingly, the copy of zlib in nodejs source has several pa
Hi,
So you work on oldstable.
Could you check for stable/testing/unstable/experimental ? And mark
the bug with found /not found.
Thanks
Bastien
Le dim. 19 sept. 2021 à 18:03, Ondrej Zary a écrit :
>
> There's no such patch in 10.24.0~dfsg-1~deb10u1
>
> --
> Ondrej Zary
There's no such patch in 10.24.0~dfsg-1~deb10u1
--
Ondrej Zary
Le dim. 19 sept. 2021 à 17:40, Ondrej Zary a écrit :
>
> Upstream node rebuilt in Debian works. So it's not a compiler or libc problem.
Does removing the debian patch
large_pages_assembly_gnu_stack.patch
Changes something ?
Bastien
> The Debian (buster) i386 version 10.24.0~dfsg-1~deb10u1 alr
Upstream node rebuilt in Debian works. So it's not a compiler or libc problem.
The Debian (buster) i386 version 10.24.0~dfsg-1~deb10u1 already contains SSE2
instructions - it does not work on Pentium 3:
$ node
Illegal instruction
So I doubt that changing -march would help.
--
Ondrej Zary
Le dim. 19 sept. 2021 à 16:33, Ondrej Zary a écrit :
>
> upstream (strings in bin/node), seems to be statically linked:
> gcc 6.3.1
> libc 2.17 according to https://github.com/nodejs/unofficial-builds/
> build log found at
> https://unofficial-builds.nodejs.org/logs/202102231620-v10.24.0/x86.log
upstream (strings in bin/node), seems to be statically linked:
gcc 6.3.1
libc 2.17 according to https://github.com/nodejs/unofficial-builds/
build log found at
https://unofficial-builds.nodejs.org/logs/202102231620-v10.24.0/x86.log
Debian binary seems to be split into libnode64.
gcc (Debian 8.3.0
Le dim. 19 sept. 2021 à 15:48, Ondrej Zary a écrit :
>
> Seems that only Debian i386 build of nodejs is broken.
>
> Downloaded
> https://unofficial-builds.nodejs.org/download/release/v10.24.0/node-v10.24.0-linux-x86.tar.xz
> unpacked somewhere and edited /usr/bin/yarnpkg to point to the new bin/n
Seems that only Debian i386 build of nodejs is broken.
Downloaded
https://unofficial-builds.nodejs.org/download/release/v10.24.0/node-v10.24.0-linux-x86.tar.xz
unpacked somewhere and edited /usr/bin/yarnpkg to point to the new bin/node
added symlinks (dirty hack) so node can find both /usr/lib/no
It works from amd64 chroot on the same machine. The i386 nodejs is broken.
--
Ondrej Zary
I've just hit this bug while upgrading gitlab from stretch to buster.
"yarnpkg install" (run in postinst) segfaults:
Thread 1 "node" received signal SIGSEGV, Segmentation fault.
0xf6fdfb5b in node::fs::FSReqWrap::~FSReqWrap() () from
/usr/lib/i386-linux-gnu/libnode.so.64
#0 0xf6fdfb5b in node::f
Package: nodejs
Version: 12.22.5~dfsg-2~11u1
Followup-For: Bug #922075
X-Debbugs-Cc: kexybisc...@outlook.com
Dear Maintainer,
I met this problem too on latest stable system, minimal repro and backtrace at
https://pastebin.aosc.io/paste/INsQkzMR6S1sSnh3mLT47g .
-- System Information:
Debian Rel
On Tue, 31 Mar 2020, Christian Walther wrote:
> Any news on this? I am seeing the same crash (same gdb backtrace) with
> the nodejs 10.15.2~dfsg-2 and npm 5.8.0+ds6-4 provided by Debian 10 i386
> (on a virtual machine) while using "npm install" on an internal package.
We also have experienced this
Any news on this? I am seeing the same crash (same gdb backtrace) with the
nodejs 10.15.2~dfsg-2 and npm 5.8.0+ds6-4 provided by Debian 10 i386 (on a
virtual machine) while using "npm install" on an internal package.
$ lscpu
Architecture:i686
CPU op-mode(s): 32-bit, 64-bit
Byte Orde
Le ven. 5 avr. 2019 à 18:31, Bernhard Übelacker a
écrit :
> Hello Jérémy,
> sorry for the delay.
>
>
> > So if i run qemu with the first P6 cpu that comes to mind, pentiumpro,
> > npm install electron-spellchecker@1.1.2
> > no longer crashes.
> >
> > That doesn't prove there is no crash on a supp
Hello Jérémy,
sorry for the delay.
> So if i run qemu with the first P6 cpu that comes to mind, pentiumpro,
> npm install electron-spellchecker@1.1.2
> no longer crashes.
>
> That doesn't prove there is no crash on a supported cpu, but that's a start.
> Comparing the flags and address sizes might
Le ven. 29 mars 2019 à 14:22, Bernhard Übelacker a
écrit :
> Hello Jérémy,
>
> Am 29.03.19 um 12:44 schrieb Jérémy Lal:
> > This fails too:
> > yarnpkg add electron-spellchecker@1.1.2
> >
> > Are you all doing this on qemu or on real hardware ?
> > On i686 ?
> > I'm asking because buster does not
Hello Jérémy,
Am 29.03.19 um 12:44 schrieb Jérémy Lal:
> This fails too:
> yarnpkg add electron-spellchecker@1.1.2
>
> Are you all doing this on qemu or on real hardware ?
> On i686 ?
> I'm asking because buster does not support i586, nor does nodejs,
> and it seems qemu defaults to something < i
Control: reassign -1 nodejs
This fails too:
yarnpkg add electron-spellchecker@1.1.2
Are you all doing this on qemu or on real hardware ?
On i686 ?
I'm asking because buster does not support i586, nor does nodejs,
and it seems qemu defaults to something < i686 (to be verified).
Jérémy
Le jeu. 28 mars 2019 à 11:58, Bernhard Übelacker a
écrit :
> Hello Jérémy Lal,
> unfortunately yes, it still crashes.
>
> Attached file shows a test starting with a minimal up-to-date
> Buster i386 qemu VM, and as far as I see after the crash
> /usr/local/lib/node_modules does not exist and follo
Hello Jérémy Lal,
unfortunately yes, it still crashes.
Attached file shows a test starting with a minimal up-to-date
Buster i386 qemu VM, and as far as I see after the crash
/usr/local/lib/node_modules does not exist and following command
shows just these files in ~/node_modules, so I can assume
i
Le jeu. 28 mars 2019 à 00:51, Bernhard Übelacker a
écrit :
> Hello Everyone,
> I tried to track down when this crash got introduced into testing.
>
Can you check it still crashes with node-gyp 3.8.0-6 (#921625),
while making sure it's not a locally installed copy that is used from
./node_modules
Hello Everyone,
I tried to track down when this crash got introduced into testing.
It still did not crash at 2019-01-31.
(While still not succeeding because of a linker error.)
The next day these packages transitioned into testing:
- apparmor iso-codes libapparmor1 libsqlite3-0 sysvinit-utils
Here's a gdb backtrace from /usr/bin/node when ran with
"run /usr/bin/npm --verbose install electron-spellchecker@1.1.2":
Thread 1 "npm" received signal SIGSEGV, Segmentation fault.
0xb70128ab in node::fs::FSReqWrap::~FSReqWrap() () from
/usr/lib/i386-linux-gnu/libnode.so.64
(gdb) bt
#0 0xb7
On Tue, Feb 12, 2019 at 12:01 AM, Jérémy Lal
wrote:
Do you get some log in ~/.npm ?
Since nodejs has a test suite, and since it crashes when extracting
tgz,
obvious culprit is node-tar, but i can't shoot something blindly if i
don't
have a (javascript) stack trace.
No, I don't see any
Le lun. 11 févr. 2019 à 20:39, Teemu Ikonen a écrit :
> Package: npm
> Version: 5.8.0+ds6-3
> Severity: normal
>
> I get a repeatable segfault from npm install by doing the following on
> i386 (deleting the local .npm and node_modules dirs is not needed to
> reproduce).
>
> -*-
>
> $ rm -rf .npm/
Package: npm
Version: 5.8.0+ds6-3
Severity: normal
I get a repeatable segfault from npm install by doing the following on
i386 (deleting the local .npm and node_modules dirs is not needed to
reproduce).
-*-
$ rm -rf .npm/
$ rm -rf node_modules/
$ npm --verbose install electron-spellchecker@1.1.2
72 matches
Mail list logo
