Bug#922075: npm: segfault during extract on i386

[Teemu Ikonen]

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-s...@1.1.2
npm info it worked if it ends with ok
npm WARN npm npm does not support Node.js v10.15.1
npm WARN npm You should probably upgrade to a newer version of node as we
npm WARN npm can't make any promises that npm will work with this version.
npm WARN npm Supported releases of Node.js are the latest release of 4, 6, 7, 8, 9.
npm WARN npm You can find the latest version at https://nodejs.org/
npm verb cli [ '/usr/bin/node',
npm verb cli '/usr/bin/npm',
npm verb cli '--verbose',
npm verb cli 'install',
npm verb cli 'electron-s...@1.1.2' ]
npm info using n...@5.8.0
npm info using no...@v10.15.1
npm verb config Skipping project config: /home/tpikonen/.npmrc. (matches userconfig)
npm verb npm-session 07474421384f9f89
npm http fetch GET 200 https://registry.npmjs.org/electron-spellchecker 259ms
npm http fetch GET 200 https://registry.npmjs.org/bcp47 118ms
npm http fetch GET 200 https://registry.npmjs.org/debug 189ms
npm http fetch GET 200 https://registry.npmjs.org/electron-remote 192ms
npm http fetch GET 200 https://registry.npmjs.org/@paulcbetts%2fcld 227ms
npm http fetch GET 200 https://registry.npmjs.org/keyboard-layout 227ms
npm http fetch GET 200 https://registry.npmjs.org/spawn-rx 104ms
npm http fetch GET 200 https://registry.npmjs.org/pify 241ms
npm http fetch GET 200 https://registry.npmjs.org/lru-cache 247ms
npm http fetch GET 200 https://registry.npmjs.org/@paulcbetts%2fspellchecker 258ms
npm http fetch GET 200 https://registry.npmjs.org/debug/-/debug-2.6.9.tgz 97ms
npm http fetch GET 200 https://registry.npmjs.org/rxjs-serial-subscription 321ms
npm http fetch GET 200 https://registry.npmjs.org/pify/-/pify-2.3.0.tgz 100ms
npm http fetch GET 200 https://registry.npmjs.org/rxjs 421ms
npm http fetch GET 200 https://registry.npmjs.org/spawn-rx/-/spawn-rx-2.0.12.tgz 204ms
npm http fetch GET 200 https://registry.npmjs.org/underscore 51ms
npm http fetch GET 200 https://registry.npmjs.org/glob 54ms
npm http fetch GET 200 https://registry.npmjs.org/ms 35ms
npm http fetch GET 200 https://registry.npmjs.org/ms/-/ms-2.0.0.tgz 42ms
npm http fetch GET 200 https://registry.npmjs.org/lodash.get 51ms
npm http fetch GET 200 https://registry.npmjs.org/xmlhttprequest 57ms
npm http fetch GET 200 https://registry.npmjs.org/hashids 68ms
npm http fetch GET 200 https://registry.npmjs.org/symbol-observable 33ms
npm http fetch GET 200 https://registry.npmjs.org/nan 49ms
npm http fetch GET 200 https://registry.npmjs.org/event-kit 59ms
npm http fetch GET 200 https://registry.npmjs.org/yallist 36ms
npm http fetch GET 200 https://registry.npmjs.org/pseudomap 43ms
npm http fetch GET 200 https://registry.npmjs.org/yallist/-/yallist-2.1.2.tgz 36ms
npm http fetch GET 200 https://registry.npmjs.org/lodash.assign 39ms
npm verb correctMkdir /home/tpikonen/.npm/_locks correctMkdir not in flight; initializing
npm verb makeDirectory /home/tpikonen/.npm/_locks creation not in flight; initializing
npm verb lock using /home/tpikonen/.npm/_locks/staging-1ec0d591837db4e7.lock for /home/tpikonen/node_modules/.staging
npm http fetch GET 200 https://registry.npmjs.org/hashids/-/hashids-1.2.2.tgz 316ms
npm http fetch GET 200 https://registry.npmjs.org/pseudomap/-/pseudomap-1.0.2.tgz 313ms
npm http fetch GET 200 https://registry.npmjs.org/event-kit/-/event-kit-2.5.3.tgz 320ms
npm http fetch GET 200 https://registry.npmjs.org/lodash.get/-/lodash.get-4.4.2.tgz 316ms
npm http fetch GET 200 https://registry.npmjs.org/symbol-observable/-/symbol-observable-1.0.1.tgz 322ms
npm WARN tar write after end
npm http fetch GET 200 https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.11.tgz 497ms
Segmentation fault.] / extract:brace-expansion: sill extract brace-e...@1.1.11 extracted to /home/tpikonen/node_modules/.staging/brace-expansion-3f1cd090

-*-

On repeated runs the package being extracted is not always the same, but
the segfault happens when the first package is extracted.

This bug is probably not in npm, but in the interpreter. I'll let you
sort that out though.

Here's my /proc/cpuinfo for reference:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz
stepping : 6
microcode : 0xc7
cpu MHz : 1333.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl
vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow dtherm
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 4322.57
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:


-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-8-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages npm depends on:
ii ca-certificates 20190110
ii node-abbrev 1.1.1-1
ii node-ansi 0.3.0-2
ii node-ansi-regex 3.0.0-1
ii node-ansistyles 0.1.3-1
ii node-aproba 1.2.0-1
ii node-archy 1.0.0-1
ii node-bluebird 3.5.1+dfsg2-2
ii node-boxen 1.2.2-1
ii node-cacache 11.3.2-2
ii node-call-limit 1.1.0-1
ii node-chownr 1.1.1-1
ii node-config-chain 1.1.11-1
ii node-detect-indent 5.0.0-1
ii node-detect-newline 2.1.0-1
ii node-editor 1.0.0-1
ii node-encoding 0.1.12-2
ii node-errno 0.1.4-1
ii node-from2 2.3.0-1
ii node-fs-vacuum 1.2.10-2
ii node-fs-write-stream-atomic 1.0.10-4
ii node-glob 7.1.3-2
ii node-graceful-fs 4.1.11-1
ii node-gyp 3.8.0-4
ii node-has-unicode 2.0.1-2
ii node-hosted-git-info 2.7.1-1
ii node-iferr 1.0.2-1
ii node-import-lazy 3.0.0.REALLY.2.1.0-1
ii node-inflight 1.0.6-1
ii node-inherits 2.0.3-1
ii node-ini 1.3.5-1
ii node-is-npm 1.0.0-1
ii node-json-parse-better-errors 1.0.2-2
ii node-jsonstream 1.3.2-1
ii node-latest-version 3.1.0-1
ii node-lazy-property 1.0.0-3
ii node-libnpx 10.2.0-2
ii node-lockfile 1.0.4-1
ii node-lru-cache 5.1.1-3
ii node-mississippi 3.0.0-1
ii node-mkdirp 0.5.1-1
ii node-move-concurrently 1.0.1-2
ii node-nopt 3.0.6-3
ii node-normalize-package-data 2.4.0-1
ii node-npm-package-arg 6.0.0-2
ii node-npmlog 4.1.2-1
ii node-once 1.4.0-3
ii node-opener 1.4.3-1
ii node-osenv 0.1.5-1
ii node-path-is-inside 1.0.2-1
ii node-promise-inflight 1.0.1-1
ii node-promzard 0.3.0-1
ii node-qw 1.0.1-1
ii node-read 1.0.7-1
ii node-read-package-json 2.0.13-1
ii node-request 2.88.1-2
ii node-resolve-from 4.0.0-1
ii node-retry 0.10.1-1
ii node-rimraf 2.6.2-1
ii node-safe-buffer 5.1.2-1
ii node-semver 5.5.1-1
ii node-semver-diff 2.1.0-2
ii node-sha 2.0.1-1
ii node-slide 1.1.6-2
ii node-sorted-object 2.0.1-1
ii node-ssri 5.2.4-2
ii node-stream-iterate 1.2.0-4
ii node-strip-ansi 4.0.0-1
ii node-tar 4.4.6+ds1-3
ii node-text-table 0.2.0-2
ii node-uid-number 0.0.6-1
ii node-unique-filename 1.1.0+ds-2
ii node-unpipe 1.0.0-1
ii node-validate-npm-package-name 3.0.0-1
ii node-which 1.3.0-2
ii node-wrappy 1.0.2-1
ii node-write-file-atomic 2.3.0-1
ii node-xdg-basedir 3.0.0-1
ii nodejs 10.15.1~dfsg-2

npm recommends no packages.

npm suggests no packages.

-- no debconf information

[Jérémy Lal]

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.

Jérémy

[tpikonen]

On Tue, Feb 12, 2019 at 12:01 AM, Jérémy Lal <kap...@melix.org>
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 logs under ~/.npm. If you have an idea on how to
get one, let me know.

Best,
Teemu

[tpikonen]

Here's a gdb backtrace from /usr/bin/node when ran with
"run /usr/bin/npm --verbose install electron-s...@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 0xb70128ab in node::fs::FSReqWrap::~FSReqWrap() () from
/usr/lib/i386-linux-gnu/libnode.so.64
#1 0xb7004323 in node::fs::FSReqAfterScope::~FSReqAfterScope() () from
/usr/lib/i386-linux-gnu/libnode.so.64
#2 0xb700458e in node::fs::AfterInteger(uv_fs_s*) () from
/usr/lib/i386-linux-gnu/libnode.so.64
#3 0xb6ad2690 in uv.work_done () from
/usr/lib/i386-linux-gnu/libuv.so.1
#4 0xb6ad677e in ?? () from /usr/lib/i386-linux-gnu/libuv.so.1
#5 0xb6ae6468 in uv.io_poll () from /usr/lib/i386-linux-gnu/libuv.so.1
#6 0xb6ad7146 in uv_run () from /usr/lib/i386-linux-gnu/libuv.so.1
#7 0xb6fd3d16 in node::Start(v8::Isolate*, node::IsolateData*,
std::vector<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > > const&,
std::vector<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > > > const&) ()
from /usr/lib/i386-linux-gnu/libnode.so.64
#8 0xb6fd2072 in node::Start(int, char**) () from
/usr/lib/i386-linux-gnu/libnode.so.64
#9 0x08049158 in main ()

Best,
Teemu

[Bernhard Übelacker]

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
-> made no difference - no crash

- node-gyp
-> pulled in libnode64 and nodejs-dev in version 10.15.0~dfsg-10
but still no crash.

- nodejs nodejs-doc
-> both got updated from 8.11.2~dfsg-1 to 10.15.0~dfsg-10
now we get the described crash.

Should this bug be reassigned to nodejs?

Unfortunately also found no *.log after it crashed.

Below is also a backtrace with current Buster and
all debug symbols installed.

Kind regards,
Bernhard


(gdb) bt
#0 0xb6f4723b in std::default_delete<node::fs::FSContinuationData>::operator() (this=0x8e12b5c, __ptr=0x1085) at /usr/include/c++/8/bits/unique_ptr.h:347
#1 std::unique_ptr<node::fs::FSContinuationData, std::default_delete<node::fs::FSContinuationData> >::~unique_ptr (this=0x8e12b5c, __in_chrg=<optimized out>) at /usr/include/c++/8/bits/unique_ptr.h:274
#2 node::fs::FSReqBase::~FSReqBase (this=0x8e12a10, __in_chrg=<optimized out>) at ../src/node_file.h:66
#3 node::fs::FSReqWrap::~FSReqWrap (this=0x8e12a10, __in_chrg=<optimized out>) at ../src/node_file.h:130
#4 node::fs::FSReqWrap::~FSReqWrap (this=0x8e12a10, __in_chrg=<optimized out>) at ../src/node_file.h:130
#5 0xb6f384b3 in node::fs::FSReqAfterScope::~FSReqAfterScope (this=0xbffe2764, __in_chrg=<optimized out>) at ../src/node_file.cc:462
#6 0xb6f38f5e in node::fs::AfterInteger (req=0x8e12a3c) at ../src/node_file.cc:512
#7 0xb6a07690 in uv__work_done (handle=0xb6a2d200 <default_loop_struct+96>) at src/threadpool.c:313
#8 0xb6a0b77e in uv__async_io (loop=0xb6a2d1a0 <default_loop_struct>, w=<optimized out>, events=<optimized out>) at src/unix/async.c:118
#9 0xb6a1b468 in uv__io_poll (loop=<optimized out>, timeout=<optimized out>) at src/unix/linux-core.c:378
#10 0xb6a0c146 in uv_run (loop=0xb6a2d1a0 <default_loop_struct>, mode=UV_RUN_DEFAULT) at src/unix/core.c:370
#11 0xb6f07e96 in node::Start (isolate=0x89c7160, isolate_data=0x8a137d0, args=std::vector of length 5, capacity 5 = {...}, exec_args=std::vector of length 0, capacity 0) at ../src/env-inl.h:661
#12 0xb6f05ef2 in node::Start (exec_args=std::vector of length 0, capacity 0, args=..., event_loop=<optimized out>) at ../src/node.cc:2969
#13 node::Start (argc=5, argv=<optimized out>) at ../src/node.cc:3029
#14 0x08049158 in main (argc=5, argv=0xbffe6574) at ../src/node_main.cc:124

[Jérémy Lal]

Le jeu. 28 mars 2019 à 00:51, Bernhard Übelacker <bern...@mailbox.org> 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/gyp or /usr/local/lib/node_modules.

Thanks !

[Bernhard Übelacker]

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
it took gyp from the installed package?

benutzer@debian:~$ find -iname "*gyp*"
./node_modules/.staging/@paulcbetts/spellchecker-c39cd101/binding.gyp
./node_modules/.staging/keyboard-layout-87dfeaf6/binding.gyp

Kind regards,
Bernhard

[Jérémy Lal]

looks right.

I'm setting up a i386 qemu vm as well, maybe i'll find what's going on.

 Jérémy

[Jérémy Lal]

Control: reassign -1 nodejs

This fails too:

yarnpkg add electron-s...@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

 

[Bernhard Übelacker]

Hello Jérémy,

Am 29.03.19 um 12:44 schrieb Jérémy Lal:

> This fails too:
> yarnpkg add electron-s...@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).

I tested just inside qemu.
Teemu Ikonen's original report looks like on real hardware.

Other cases where cpu features were related, the process
usually gets a SIGILL on a instruction not supported.
In this case we get SIGSEGV on a mov instruction, which
is quite common I guess.
So I am not sure, if in this case the cpu is the issue.

Qemu can also use other cpu configurations like "-M max"
or "-M host". That way it should be able to do all what the
host is able to? Have not tested such a configuration.

I have repeated the test on real hardware and it crashes
the same as in the VM. I hope buster is supported on
this hardware?

Kind regards,
Bernhard



Real hardware:
root@debian-athlonx2-32:~# lscpu
Architecture: i686
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 40 bits physical, 48 bits virtual
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
Vendor ID: AuthenticAMD
CPU family: 15
Model: 107
Model name: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
Stepping: 1
CPU MHz: 1000.000
CPU max MHz: 2600,0000
CPU min MHz: 1000,0000
BogoMIPS: 2009.24
Virtualization: AMD-V
L1d cache: 64K
L1i cache: 64K
L2 cache: 512K
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good cpuid extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch vmmcall lbrv

Mär 29 14:10:10 debian-athlonx2-32 kernel: npm[5417]: segfault at 1085 ip b6f9023b sp bfd1a1b4 error 4 in libnode.so.64[b6eb4000+b4a000]
Mär 29 14:10:10 debian-athlonx2-32 kernel: Code: 01 00 00 85 c0 74 16 8d 96 6c 01 00 00 39 d0 74 0c 83 ec 0c 50 e8 f5 14 f5 ff 83 c4 10 8b 86 4c 01 00 00 85 c0 74 0c 83 ec 0c <8b>
10 50 ff 52 04 83 c4 10 8b 83 54 69 01 00 8b 4e 04 83 c0 08 89

######


Inside my qemu i386 VM with default cpu:
root@debian:~# lscpu
Architecture: i686
CPU op-mode(s): 32-bit
Byte Order: Little Endian
Address sizes: 36 bits physical, 32 bits virtual
CPU(s): 14
On-line CPU(s) list: 0-13
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 14
Vendor ID: AuthenticAMD
CPU family: 6
Model: 6
Model name: QEMU Virtual CPU version 2.5+
Stepping: 3
CPU MHz: 2994.374
BogoMIPS: 5988.74
Hypervisor vendor: KVM
Virtualization type: full
Flags: fpu de pse tsc msr pae mce cx8 apic sep pge cmov pat mmx fxsr sse sse2 cpuid tsc_known_freq pni x2apic hypervisor vmmcall


######


$ qemu-system-i386 -cpu help
...
x86 host KVM processor with all supported host features
x86 max Enables all features supported by the accelerator in the current host

[Jérémy Lal]

Le ven. 29 mars 2019 à 14:22, Bernhard Übelacker <bern...@mailbox.org> a écrit :

Hello Jérémy,

Am 29.03.19 um 12:44 schrieb Jérémy Lal:
> This fails too:
> yarnpkg add electron-s...@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).

I tested just inside qemu.
Teemu Ikonen's original report looks like on real hardware.

Other cases where cpu features were related, the process
usually gets a SIGILL on a instruction not supported.
In this case we get SIGSEGV on a mov instruction, which
is quite common I guess.
So I am not sure, if in this case the cpu is the issue.

Qemu can also use other cpu configurations like "-M max"
or "-M host". That way it should be able to do all what the
host is able to? Have not tested such a configuration.

I have repeated the test on real hardware and it crashes
the same as in the VM. I hope buster is supported on
this hardware?

Buster release notes:

"""

Nearly all x86-based (IA-32) processors still in use in personal computers are supported.

This also includes 32-bit AMD and VIA (former Cyrix) processors, and processors like the

Athlon XP and Intel P4 Xeon.
However, Debian GNU/Linux buster will not run on 586 (Pentium) or earlier processors.

"""

I let you check if that's all right for your host cpu.

So if i run qemu with the first P6 cpu that comes to mind, pentiumpro,

npm install electron-s...@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 help.

Also upstream nodejs does not support 32bit cpu on linux platform.

Jérémy

[Jérémy Lal]

Le ven. 5 avr. 2019 à 18:31, Bernhard Übelacker <bern...@mailbox.org> 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-s...@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 help.
> Also upstream nodejs does not support 32bit cpu on linux platform.

Unfortunately my debian QEmu does not have a cpu "pentiumpro".
(qemu-system-i386 -cpu help)

That's odd ! We should have the same options ?

I tried to debug it at real hardware, which also supports rr [1].
Unfortunately there I hit a bug in rr that rr-upstream fixed very fast [2].

At this real hardware [3] I could reproduce this bug with i386 userlands
runnning at amd64- or i386-kernel. I assume that should be a supported CPU.

I tried to follow that value 0x1085, that is shown in the original report
and in all my debugging attempts, by reverse debugging.
But unfortunately that led to no certain findings.

That's surely very hard to catch since v8 is generating assembly on the fly.

I'll try to get some info from upstream.

Jérémy

 

Kind regards,
Bernhard


[1] https://rr-project.org/
[2] https://github.com/mozilla/rr/issues/2342

[3] Architecture:        x86_64

    CPU op-mode(s):      32-bit, 64-bit
    Byte Order:          Little Endian

    Address sizes:       36 bits physical, 48 bits virtual
    Vendor ID:           GenuineIntel
    CPU family:          6
    Model name:          Intel(R) Pentium(R) CPU B950 @ 2.10GHz

[Christian Walther]

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 Order: Little Endian

Address sizes: 40 bits physical, 48 bits virtual
CPU(s): 1
On-line CPU(s) list: 0

Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 1

Vendor ID: GenuineIntel
CPU family: 6

Model: 60
Model name: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz
Stepping: 3
CPU MHz: 3599.996
BogoMIPS: 7199.99
Hypervisor vendor: VMware
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 8192K
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss nx pdpe1gb rdtscp lm constant_tsc arch_perfmon xtopology tsc_reliable nonstop_tsc cpuid pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cpuid_fault pti ssbd ibrs ibpb stibp fsgsbase smep arat flush_l1d arch_capabilities

$ cat /proc/version
Linux version 4.19.0-8-686-pae (debian...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.98-1 (2020-01-26)

[Raphael Hertzog]

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 segfault in Kali while trying to build a
package on .

I'm wondering why this bug was not forwarded upstream?

I know that linux 32 bit is no longer officially supported by
upstream, but are they rejecting bug reports?

It seems that "unofficial builds" are still made and thus bug
reports and fixes are likely accepted, though not handled with
any priority I guess. That would still give more visibility to this issue.

https://unofficial-builds.nodejs.org/

I'm also wondering why i386 and armel are treated differently, given that
both are unsupported upstream (in Debian, i386 is still built, but armel
is no longer built).

Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <her...@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS

[Kexy Biscuit]

Package: nodejs
Version: 12.22.5~dfsg-2~11u1
Followup-For: Bug #922075
X-Debbugs-Cc: kexyb...@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 Release: 11.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-8-686-pae (SMP w/6 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nodejs depends on:
ii libc6 2.31-13
ii libnode72 12.22.5~dfsg-2~11u1

Versions of packages nodejs recommends:
ii ca-certificates 20210119
ii nodejs-doc 12.22.5~dfsg-2~11u1

Versions of packages nodejs suggests:
ii npm 7.5.2+ds-2

-- no debconf information

[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::fs::FSReqWrap::~FSReqWrap() () from /usr/lib/i386-linux-gnu/libnode.so.64
#1 0xf6fd0a43 in node::fs::FSReqAfterScope::~FSReqAfterScope() () from /usr/lib/i386-linux-gnu/libnode.so.64
#2 0xf6fd14fe in node::fs::AfterInteger(uv_fs_s*) () from /usr/lib/i386-linux-gnu/libnode.so.64
#3 0xf6a8b662 in uv.work_done () from /usr/lib/i386-linux-gnu/libuv.so.1
#4 0xf6a8fb81 in ?? () from /usr/lib/i386-linux-gnu/libuv.so.1
#5 0xf6aa14d8 in uv.io_poll () from /usr/lib/i386-linux-gnu/libuv.so.1
#6 0xf6a90568 in uv_run () from /usr/lib/i386-linux-gnu/libuv.so.1
#7 0xf6f9ec76 in node::Start(v8::Isolate*, node::IsolateData*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >,
#8 0xf6f9cc97 in node::Start(int, char**) () from /usr/lib/i386-linux-gnu/libnode.so.64

#9 0x08049158 in main ()

Dump of assembler code for function _ZN4node2fs9FSReqWrapD0Ev:
0xf6fdfb10 <+0>: push %ebp
0xf6fdfb11 <+1>: mov %esp,%ebp
0xf6fdfb13 <+3>: push %esi
0xf6fdfb14 <+4>: push %ebx
0xf6fdfb15 <+5>: mov 0x8(%ebp),%esi
0xf6fdfb18 <+8>: call 0xf6f4d7e0
0xf6fdfb1d <+13>: add $0xfb8daf,%ebx
0xf6fdfb23 <+19>: mov 0x14240(%ebx),%eax
0xf6fdfb29 <+25>: add $0x8,%eax
0xf6fdfb2c <+28>: mov %eax,(%esi)
0xf6fdfb2e <+30>: mov 0x168(%esi),%eax
0xf6fdfb34 <+36>: test %eax,%eax
0xf6fdfb36 <+38>: je 0xf6fdfb4e <_ZN4node2fs9FSReqWrapD0Ev+62>
0xf6fdfb38 <+40>: lea 0x16c(%esi),%edx
0xf6fdfb3e <+46>: cmp %edx,%eax
0xf6fdfb40 <+48>: je 0xf6fdfb4e <_ZN4node2fs9FSReqWrapD0Ev+62>
0xf6fdfb42 <+50>: sub $0xc,%esp
0xf6fdfb45 <+53>: push %eax
0xf6fdfb46 <+54>: call 0xf6f2b630 <free@plt>
0xf6fdfb4b <+59>: add $0x10,%esp
0xf6fdfb4e <+62>: mov 0x14c(%esi),%eax
0xf6fdfb54 <+68>: test %eax,%eax
0xf6fdfb56 <+70>: je 0xf6fdfb64 <_ZN4node2fs9FSReqWrapD0Ev+84>
0xf6fdfb58 <+72>: sub $0xc,%esp
=> 0xf6fdfb5b <+75>: mov (%eax),%edx
0xf6fdfb5d <+77>: push %eax
0xf6fdfb5e <+78>: call *0x4(%edx)
0xf6fdfb61 <+81>: add $0x10,%esp
0xf6fdfb64 <+84>: mov 0x16ec8(%ebx),%eax
0xf6fdfb6a <+90>: mov 0x4(%esi),%ecx
0xf6fdfb6d <+93>: add $0x8,%eax
0xf6fdfb70 <+96>: mov %eax,(%esi)
0xf6fdfb72 <+98>: test %ecx,%ecx
0xf6fdfb74 <+100>: je 0xf6fdfba8 <_ZN4node2fs9FSReqWrapD0Ev+152>
0xf6fdfb76 <+102>: mov 0x20(%esi),%edx
0xf6fdfb79 <+105>: mov 0x24(%esi),%eax
0xf6fdfb7c <+108>: sub $0xc,%esp
0xf6fdfb7f <+111>: mov %eax,0x4(%edx)
0xf6fdfb82 <+114>: mov %edx,(%eax)
0xf6fdfb84 <+116>: push %esi
0xf6fdfb85 <+117>: call 0xf6f38eb0 <_ZN4node9AsyncWrapD2Ev@plt>
0xf6fdfb8a <+122>: pop %eax
0xf6fdfb8b <+123>: pop %edx
0xf6fdfb8c <+124>: push $0x1ac
0xf6fdfb91 <+129>: push %esi
0xf6fdfb92 <+130>: call 0xf6f152c0 <_ZdlPvj@plt>
0xf6fdfb97 <+135>: add $0x10,%esp
0xf6fdfb9a <+138>: lea -0x8(%ebp),%esp
0xf6fdfb9d <+141>: pop %ebx
0xf6fdfb9e <+142>: pop %esi
0xf6fdfb9f <+143>: pop %ebp
0xf6fdfba0 <+144>: ret
0xf6fdfba1 <+145>: lea 0x0(%esi,%eiz,1),%esi
0xf6fdfba8 <+152>: sub $0xc,%esp
0xf6fdfbab <+155>: pushl 0x16978(%ebx)
0xf6fdfbb1 <+161>: call 0xf6f1fcb0 <_ZN4node6AssertEPA4_KPKc@plt>

This is on a 64-bit CPU (P4) running i386 userspace. This does not look like a CPU problem.
It simply crashed in a C++ code.

nodejs 10.24.0~dfsg-1~deb10u1
yarnpkg 1.22.4-5~bpo10+1

--
Ondrej Zary

[Ondrej Zary]

It works from amd64 chroot on the same machine. The i386 nodejs is broken.

--
Ondrej Zary

[Ondrej Zary]

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/nodejs and /usr/share/nodejs:
/node_modules -> /usr/share/nodejs
/var/lib/gitlab/.node_libraries -> /usr/lib/nodejs

yarnpkg completed without segfault!

--
Ondrej Zary

[Bastien ROUCARIES]

Could you investigate:
- the libc used both upstream and debian side ?
- the gcc or compiler used with flags both side ?

Bastien

> --
> Ondrej Zary
>
> --
> Pkg-javascript-devel mailing list
> Pkg-javasc...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Ondrej Zary]

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-6) 8.3.0
libc6 2.28-10

I'll try to build the upstream version in Debian.

--
Ondrej Zary

[Bastien ROUCARIES]

Could you try aurel32 tips:
<aurel32> rouca: it's not obviously linked to libc
[16:34] <aurel32> rouca: about gcc, we have a very low ISA baseline on
i386 compared to what is usually used. Might be worth trying to
rebuild it with -march=pentium4 or something like that

[Ondrej Zary]

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

[Bastien ROUCARIES]

Le dim. 19 sept. 2021 à 17:40, Ondrej Zary <ond...@zary.sk> 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

[Ondrej Zary]

There's no such patch in 10.24.0~dfsg-1~deb10u1

--
Ondrej Zary

[Bastien ROUCARIES]

Hi,

So you work on oldstable.

Could you check for stable/testing/unstable/experimental ? And mark
the bug with found /not found.

Thanks

Bastien

[Jérémy Lal]

Le dim. 19 sept. 2021 à 20:18, Bastien ROUCARIES <roucarie...@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 patches that are not

in the official zlib release available in debian.

So if what was said is correct (that upstream binary builds do not crash) this might be a clue.

Jérémy

[Bastien ROUCARIES]

I was more thinking about a cflags like hardening flags or something
like this...

Bastien

> Jérémy

[Ondrej Zary]

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 upgrade gitlab further to 12 and 13 and only then I can upgrade Debian to bullseye.

I've rebuilt Debian nodejs without --shared-zlib, --shared-cares and --shared-libuv (remove them from debian/rules). It works now!

Going to narrow it down.

--
Ondrej Zary

[Bastien ROUCARIES]

begin whith shared-uv

Bastien

>
> Going to narrow it down.
>
> --
> Ondrej Zary
>

[Ondrej Zary]

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

[Bastien ROUCARIES]

Do you have valgrind ?

If so and if it work (test first on good version), it smell like a use
after free or a RAII violation

I means, that libuv free a pointer, nodejs fill the buffer with code,
then libuv free it. BOOOM.

[Ondrej Zary]

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 cflags?

--
Ondrej Zary

[Bastien ROUCARIES]

Le dim. 19 sept. 2021 à 21:25, Bastien ROUCARIES
<roucarie...@gmail.com> a écrit :
>

> Le dim. 19 sept. 2021 à 21:15, Ondrej Zary <ond...@zary.sk> 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 (test first on good version), it smell like a use
> after free or a RAII violation
>
> I means, that libuv free a pointer, nodejs fill the buffer with code,
> then libuv free it. BOOOM.

From libuv changelog
- * unix,win: fix `uv_fs_poll_stop()` when active (Anna Henningsen)
- * unix: fix race condition in uv_async_send() (Ben Noordhuis)

But I suppose it will be quicker to bissect by build/try the different
version of libuv...

Bastien

[Bastien ROUCARIES]

Le dim. 19 sept. 2021 à 21:39, Bastien ROUCARIES
<roucarie...@gmail.com> a écrit :

> Or ldflags
>
> Could you dump the cflags/ldfalgs of both version?
Or sanatizer that avoid a free after use...

We harden a lot on debian side

Bastien

[Bastien ROUCARIES]

Or ldflags

Could you dump the cflags/ldfalgs of both version?


>

[Bastien ROUCARIES]

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

[Bastien ROUCARIES]

Le dim. 19 sept. 2021 à 21:57, Bastien ROUCARIES

<roucarie...@gmail.com> 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
> <roucarie...@gmail.com> a écrit :
> >
> > Le dim. 19 sept. 2021 à 21:39, Bastien ROUCARIES
> > <roucarie...@gmail.com> a écrit :
> > >
> > > Le dim. 19 sept. 2021 à 21:36, Ondrej Zary <ond...@zary.sk> 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 libuv version but its linking (included in node or external). Or cflags?
> > > Or ldflags
> > >
> > > Could you dump the cflags/ldfalgs of both version?
> > Or sanatizer that avoid a free after use...
> >
> > We harden a lot on debian side
> >
> > Bastien
> > >
> > >
> > > >
> > > > --
> > > > Ondrej Zary

If it does work try to build both nodejs and libuv with
-fsanitize=address or other sanitizer option

Bastien

[Ondrej Zary]

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

[Bastien ROUCARIES]

Le lun. 20 sept. 2021 à 08:02, Ondrej Zary <ond...@zary.sk> 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 is time to escalade.

Bastien
> --
> Ondrej Zary

[Bastien ROUCARIES]

Le lun. 20 sept. 2021 à 12:02, Ondrej Zary <ond...@zary.sk> 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 crosscompile safe so this is a dead end

--
Ondrej Zary

[Ondrej Zary]

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

[Ondrej Zary]

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...
[---------------------------------------------------------------------------------------------------------------------------------------------------] 0/520AddressSanitizer:DEADLYSIGNAL
=================================================================
==26662==ERROR: AddressSanitizer: SEGV on unknown address 0x00001085 (pc 0xf695db5b bp 0xffd3adb8 sp 0xffd3ada4 T0)
==26662==The signal is caused by a READ memory access.
#0 0xf695db5a in node::fs::FSReqWrap::~FSReqWrap() (/lib/i386-linux-gnu/libnode.so.64+0x50bb5a)
#1 0xf694ea42 in node::fs::FSReqAfterScope::~FSReqAfterScope() (/lib/i386-linux-gnu/libnode.so.64+0x4fca42)
#2 0xf694f4fd in node::fs::AfterInteger(uv_fs_s*) (/lib/i386-linux-gnu/libnode.so.64+0x4fd4fd)
#3 0xf629e32d in uv__work_done (/lib/i386-linux-gnu/libuv.so.1+0x5f32d)
#4 0xf62ad125 (/lib/i386-linux-gnu/libuv.so.1+0x6e125)
#5 0xf631e0a8 in uv__io_poll (/lib/i386-linux-gnu/libuv.so.1+0xdf0a8)
#6 0xf62b198c in uv_run (/lib/i386-linux-gnu/libuv.so.1+0x7298c)
#7 0xf691cc75 in node::Start(v8::Isolate*, node::IsolateData*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) (/lib/i386-linux-gnu/libnode.so.64+0x4cac75)
#8 0xf691ac96 in node::Start(int, char**) (/lib/i386-linux-gnu/libnode.so.64+0x4c8c96)
#9 0x8049157 in main (/usr/bin/node+0x8049157)
#10 0xf3ac5b40 in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x1ab40)
#11 0x80491c1 in _start (/usr/bin/node+0x80491c1)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/i386-linux-gnu/libnode.so.64+0x50bb5a) in node::fs::FSReqWrap::~FSReqWrap()
==26662==ABORTING


--
Ondrej Zary

[Bastien ROUCARIES]

Ok now try to run the whole thing against valgrind...

Bastien

>
>
> --
> Ondrej Zary

[Ondrej Zary]

> 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.
==752== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==752== Command: /usr/bin/yarnpkg install
==752==
==752==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
==752==
==752== HEAP SUMMARY:
==752== in use at exit: 0 bytes in 0 blocks
==752== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==752==
==752== All heap blocks were freed -- no leaks are possible
==752==
==752== For counts of detected and suppressed errors, rerun with: -v
==752== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

valgrind with clean libuv1 (no asan):
runuser -u gitlab -- sh -c 'valgrind --trace-children=yes yarnpkg install'
==3163== Memcheck, a memory error detector
==3163== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3163== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==3163== Command: /usr/bin/yarnpkg install
==3163==
==3163== Memcheck, a memory error detector
==3163== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3163== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==3163== Command: /usr/bin/node /usr/bin/yarnpkg install
==3163==

yarn install v1.13.0
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...

[---------------------------------------------------------------------------------------------------------------------------------------------------] 0/520==3163== Invalid read of size 4
==3163== at 0x4556B5B: node::fs::FSReqWrap::~FSReqWrap() (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3163== by 0x4547A42: node::fs::FSReqAfterScope::~FSReqAfterScope() (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3163== by 0x45484FD: node::fs::AfterInteger(uv_fs_s*) (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3163== by 0x556170F: uv__work_done (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
==3163== by 0x55657FD: ??? (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
==3163== by 0x5575527: uv__io_poll (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
==3163== by 0x55661C5: uv_run (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
==3163== by 0x4515C75: node::Start(v8::Isolate*, node::IsolateData*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3163== by 0x4513C96: node::Start(int, char**) (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3163== by 0x8049157: main (in /usr/bin/node)
==3163== Address 0x1085 is not stack'd, malloc'd or (recently) free'd
==3163==
==3163==
==3163== Process terminating with default action of signal 11 (SIGSEGV)
==3163== Access not within mapped region at address 0x1085
==3163== at 0x4556B5B: node::fs::FSReqWrap::~FSReqWrap() (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3163== by 0x4547A42: node::fs::FSReqAfterScope::~FSReqAfterScope() (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3163== by 0x45484FD: node::fs::AfterInteger(uv_fs_s*) (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3163== by 0x556170F: uv__work_done (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
==3163== by 0x55657FD: ??? (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
==3163== by 0x5575527: uv__io_poll (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
==3163== by 0x55661C5: uv_run (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
==3163== by 0x4515C75: node::Start(v8::Isolate*, node::IsolateData*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3163== by 0x4513C96: node::Start(int, char**) (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3163== by 0x8049157: main (in /usr/bin/node)
==3163== If you believe this happened as a result of a stack
==3163== overflow in your program's main thread (unlikely but
==3163== possible), you can try to increase the size of the
==3163== main thread stack using the --main-stacksize= flag.
==3163== The main thread stack size used in this run was 8388608.
==3163== Invalid read of size 1
==3163== at 0x786A6A4: check_free (dlerror.c:189)
==3163== by 0x786ABD8: free_key_mem (dlerror.c:221)
==3163== by 0x786ABD8: __dlerror_main_freeres (dlerror.c:239)
==3163== by 0x7CA4667: __libc_freeres (in /usr/lib/i386-linux-gnu/libc-2.28.so)
==3163== by 0x402D1DE: _vgnU_freeres (in /usr/lib/i386-linux-gnu/valgrind/vgpreload_core-x86-linux.so)
==3163== Address 0xedbde is not stack'd, malloc'd or (recently) free'd
==3163==
==3163==
==3163== Process terminating with default action of signal 11 (SIGSEGV)
==3163== Access not within mapped region at address 0xEDBDE
==3163== at 0x786A6A4: check_free (dlerror.c:189)
==3163== by 0x786ABD8: free_key_mem (dlerror.c:221)
==3163== by 0x786ABD8: __dlerror_main_freeres (dlerror.c:239)
==3163== by 0x7CA4667: __libc_freeres (in /usr/lib/i386-linux-gnu/libc-2.28.so)
==3163== by 0x402D1DE: _vgnU_freeres (in /usr/lib/i386-linux-gnu/valgrind/vgpreload_core-x86-linux.so)
==3163== If you believe this happened as a result of a stack
==3163== overflow in your program's main thread (unlikely but
==3163== possible), you can try to increase the size of the
==3163== main thread stack using the --main-stacksize= flag.
==3163== The main thread stack size used in this run was 8388608.
==3163==
==3163== HEAP SUMMARY:
==3163== in use at exit: 1,908,342 bytes in 19,155 blocks
==3163== total heap usage: 743,018 allocs, 723,863 frees, 572,337,823 bytes allocated
==3163==
==3163== LEAK SUMMARY:
==3163== definitely lost: 78 bytes in 1 blocks
==3163== indirectly lost: 0 bytes in 0 blocks
==3163== possibly lost: 81,312 bytes in 14 blocks
==3163== still reachable: 1,826,952 bytes in 19,140 blocks
==3163== of which reachable via heuristic:
==3163== newarray : 50,384 bytes in 37 blocks
==3163== multipleinheritance: 32 bytes in 1 blocks
==3163== suppressed: 0 bytes in 0 blocks
==3163== Rerun with --leak-check=full to see details of leaked memory
==3163==
==3163== For counts of detected and suppressed errors, rerun with: -v
==3163== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Segmentation fault


--
Ondrej Zary

[Bastien ROUCARIES]

Le lun. 20 sept. 2021 à 10:20, Bastien ROUCARIES
<roucarie...@gmail.com> a écrit :
>

Could you try to build both libuv and node with -fsanitize=null it is
likely a null dereference so catch it

Bastien

[Bastien ROUCARIES]

add --track-origins=yes to valgrind

And try to rebuild the whole libuv and nodejs with -fstack-protector-all

[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== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==6122== Command: /usr/bin/yarnpkg install
==6122==
==6122== Memcheck, a memory error detector
==6122== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==6122== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==6122== Command: /usr/bin/node /usr/bin/yarnpkg install
==6122==

yarn install v1.13.0
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...

[---------------------------------------------------------------------------------------------------------------------------------------------------] 0/520==6122== Invalid read of size 4
==6122== at 0x4556B5B: node::fs::FSReqWrap::~FSReqWrap() (in /usr/lib/i386-linux-gnu/libnode.so.64)
==6122== by 0x4547A42: node::fs::FSReqAfterScope::~FSReqAfterScope() (in /usr/lib/i386-linux-gnu/libnode.so.64)
==6122== by 0x45484FD: node::fs::AfterInteger(uv_fs_s*) (in /usr/lib/i386-linux-gnu/libnode.so.64)
==6122== by 0x556170F: uv__work_done (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
==6122== by 0x55657FD: ??? (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
==6122== by 0x5575527: uv__io_poll (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
==6122== by 0x55661C5: uv_run (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
==6122== by 0x4515C75: node::Start(v8::Isolate*, node::IsolateData*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) (in /usr/lib/i386-linux-gnu/libnode.so.64)
==6122== by 0x4513C96: node::Start(int, char**) (in /usr/lib/i386-linux-gnu/libnode.so.64)
==6122== by 0x8049157: main (in /usr/bin/node)
==6122== Address 0x1085 is not stack'd, malloc'd or (recently) free'd
==6122==
==6122==
==6122== Process terminating with default action of signal 11 (SIGSEGV)
==6122== Access not within mapped region at address 0x1085
==6122== at 0x4556B5B: node::fs::FSReqWrap::~FSReqWrap() (in /usr/lib/i386-linux-gnu/libnode.so.64)
==6122== by 0x4547A42: node::fs::FSReqAfterScope::~FSReqAfterScope() (in /usr/lib/i386-linux-gnu/libnode.so.64)
==6122== by 0x45484FD: node::fs::AfterInteger(uv_fs_s*) (in /usr/lib/i386-linux-gnu/libnode.so.64)
==6122== by 0x556170F: uv__work_done (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
==6122== by 0x55657FD: ??? (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
==6122== by 0x5575527: uv__io_poll (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
==6122== by 0x55661C5: uv_run (in /usr/lib/i386-linux-gnu/libuv.so.1.0.0)
==6122== by 0x4515C75: node::Start(v8::Isolate*, node::IsolateData*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) (in /usr/lib/i386-linux-gnu/libnode.so.64)
==6122== by 0x4513C96: node::Start(int, char**) (in /usr/lib/i386-linux-gnu/libnode.so.64)
==6122== by 0x8049157: main (in /usr/bin/node)
==6122== If you believe this happened as a result of a stack
==6122== overflow in your program's main thread (unlikely but
==6122== possible), you can try to increase the size of the
==6122== main thread stack using the --main-stacksize= flag.
==6122== The main thread stack size used in this run was 8388608.
==6122== Invalid read of size 1
==6122== at 0x786A6A4: check_free (dlerror.c:189)
==6122== by 0x786ABD8: free_key_mem (dlerror.c:221)
==6122== by 0x786ABD8: __dlerror_main_freeres (dlerror.c:239)
==6122== by 0x7CA4667: __libc_freeres (in /usr/lib/i386-linux-gnu/libc-2.28.so)
==6122== by 0x402D1DE: _vgnU_freeres (in /usr/lib/i386-linux-gnu/valgrind/vgpreload_core-x86-linux.so)
==6122== Address 0x16708c is not stack'd, malloc'd or (recently) free'd
==6122==
==6122==
==6122== Process terminating with default action of signal 11 (SIGSEGV)
==6122== Access not within mapped region at address 0x16708C
==6122== at 0x786A6A4: check_free (dlerror.c:189)
==6122== by 0x786ABD8: free_key_mem (dlerror.c:221)
==6122== by 0x786ABD8: __dlerror_main_freeres (dlerror.c:239)
==6122== by 0x7CA4667: __libc_freeres (in /usr/lib/i386-linux-gnu/libc-2.28.so)
==6122== by 0x402D1DE: _vgnU_freeres (in /usr/lib/i386-linux-gnu/valgrind/vgpreload_core-x86-linux.so)
==6122== If you believe this happened as a result of a stack
==6122== overflow in your program's main thread (unlikely but
==6122== possible), you can try to increase the size of the
==6122== main thread stack using the --main-stacksize= flag.
==6122== The main thread stack size used in this run was 8388608.
==6122==
==6122== HEAP SUMMARY:
==6122== in use at exit: 2,476,037 bytes in 19,127 blocks
==6122== total heap usage: 748,937 allocs, 729,810 frees, 578,044,456 bytes allocated
==6122==
==6122== LEAK SUMMARY:
==6122== definitely lost: 78 bytes in 1 blocks
==6122== indirectly lost: 0 bytes in 0 blocks
==6122== possibly lost: 280,792 bytes in 24 blocks
==6122== still reachable: 2,195,167 bytes in 19,102 blocks
==6122== of which reachable via heuristic:
==6122== newarray : 50,968 bytes in 38 blocks
==6122== multipleinheritance: 32 bytes in 1 blocks
==6122== suppressed: 0 bytes in 0 blocks
==6122== Rerun with --leak-check=full to see details of leaked memory
==6122==
==6122== For counts of detected and suppressed errors, rerun with: -v
==6122== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Segmentation fault


--
Ondrej Zary

[Ondrej Zary]

> And try to rebuild the whole libuv and nodejs with -fstack-protector-all

Does not print anything other than Segmentation fault.

--
Ondrej Zary

[Bastien ROUCARIES]

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

[Ondrej Zary]

> 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=yes --trace-children=yes --track-origins=yes yarnpkg install'
==3423== Memcheck, a memory error detector
==3423== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3423== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==3423== Command: /usr/bin/yarnpkg install
==3423==
==3423== Memcheck, a memory error detector
==3423== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3423== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==3423== Command: /usr/bin/node /usr/bin/yarnpkg install
==3423==

yarn install v1.13.0
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...

[---------------------------------------------------------------------------------------------------------------------------------------------------] 0/520==3423== Invalid read of size 4
==3423== at 0x4556B5B: node::fs::FSReqWrap::~FSReqWrap() (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3423== by 0x4547A42: node::fs::FSReqAfterScope::~FSReqAfterScope() (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3423== by 0x45484FD: node::fs::AfterInteger(uv_fs_s*) (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3423== by 0x556170F: uv__work_done (threadpool.c:313)
==3423== by 0x55657FD: uv__async_io.part.0 (async.c:118)
==3423== by 0x5575527: uv__io_poll (linux-core.c:378)
==3423== by 0x55661C5: uv_run (core.c:370)
==3423== by 0x4515C75: node::Start(v8::Isolate*, node::IsolateData*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3423== by 0x4513C96: node::Start(int, char**) (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3423== by 0x8049157: main (in /usr/bin/node)
==3423== Address 0x410 is not stack'd, malloc'd or (recently) free'd
==3423==
==3423==
==3423== Process terminating with default action of signal 11 (SIGSEGV)
==3423== Access not within mapped region at address 0x410
==3423== at 0x4556B5B: node::fs::FSReqWrap::~FSReqWrap() (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3423== by 0x4547A42: node::fs::FSReqAfterScope::~FSReqAfterScope() (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3423== by 0x45484FD: node::fs::AfterInteger(uv_fs_s*) (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3423== by 0x556170F: uv__work_done (threadpool.c:313)
==3423== by 0x55657FD: uv__async_io.part.0 (async.c:118)
==3423== by 0x5575527: uv__io_poll (linux-core.c:378)
==3423== by 0x55661C5: uv_run (core.c:370)
==3423== by 0x4515C75: node::Start(v8::Isolate*, node::IsolateData*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3423== by 0x4513C96: node::Start(int, char**) (in /usr/lib/i386-linux-gnu/libnode.so.64)
==3423== by 0x8049157: main (in /usr/bin/node)
==3423== If you believe this happened as a result of a stack
==3423== overflow in your program's main thread (unlikely but
==3423== possible), you can try to increase the size of the
==3423== main thread stack using the --main-stacksize= flag.
==3423== The main thread stack size used in this run was 8388608.
==3423== Invalid read of size 1
==3423== at 0x786A6A4: check_free (dlerror.c:189)
==3423== by 0x786ABD8: free_key_mem (dlerror.c:221)
==3423== by 0x786ABD8: __dlerror_main_freeres (dlerror.c:239)
==3423== by 0x7CA4667: __libc_freeres (in /usr/lib/i386-linux-gnu/libc-2.28.so)
==3423== by 0x402D1DE: _vgnU_freeres (in /usr/lib/i386-linux-gnu/valgrind/vgpreload_core-x86-linux.so)
==3423== Address 0x16b6b3 is not stack'd, malloc'd or (recently) free'd
==3423==
==3423==
==3423== Process terminating with default action of signal 11 (SIGSEGV)
==3423== Access not within mapped region at address 0x16B6B3
==3423== at 0x786A6A4: check_free (dlerror.c:189)
==3423== by 0x786ABD8: free_key_mem (dlerror.c:221)
==3423== by 0x786ABD8: __dlerror_main_freeres (dlerror.c:239)
==3423== by 0x7CA4667: __libc_freeres (in /usr/lib/i386-linux-gnu/libc-2.28.so)
==3423== by 0x402D1DE: _vgnU_freeres (in /usr/lib/i386-linux-gnu/valgrind/vgpreload_core-x86-linux.so)
==3423== If you believe this happened as a result of a stack
==3423== overflow in your program's main thread (unlikely but
==3423== possible), you can try to increase the size of the
==3423== main thread stack using the --main-stacksize= flag.
==3423== The main thread stack size used in this run was 8388608.
==3423==
==3423== HEAP SUMMARY:
==3423== in use at exit: 2,438,165 bytes in 19,093 blocks
==3423== total heap usage: 745,428 allocs, 726,335 frees, 579,085,241 bytes allocated
==3423==
==3423== LEAK SUMMARY:
==3423== definitely lost: 78 bytes in 1 blocks
==3423== indirectly lost: 0 bytes in 0 blocks
==3423== possibly lost: 240,896 bytes in 22 blocks
==3423== still reachable: 2,197,191 bytes in 19,070 blocks
==3423== of which reachable via heuristic:
==3423== newarray : 54,472 bytes in 44 blocks
==3423== multipleinheritance: 32 bytes in 1 blocks
==3423== suppressed: 0 bytes in 0 blocks
==3423== Rerun with --leak-check=full to see details of leaked memory
==3423==
==3423== For counts of detected and suppressed errors, rerun with: -v
==3423== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Segmentation fault
# dpkg -l | grep dbgsym
ii libnode64-dbgsym:i386 10.24.0~dfsg-1~deb10u1 i386 debug symbols for libnode64
ii libuv1-dbgsym:i386 1.24.1-1+deb10u1 i386 debug symbols for libuv1
ii nodejs-dbgsym 10.24.0~dfsg-1~deb10u1 i386 debug symbols for nodejs


--
Ondrej Zary

[Bastien ROUCARIES]

Could you try to apply

https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4

I think it describe that you see

Bastien

[Ondrej Zary]

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.

--
Ondrej Zary

[Bastien ROUCARIES]

Ok as band aid could you replace in the patch BaseObjectPtr by
std:shared_ptr<ObjectPtr>

Bastien

[Bastien ROUCARIES]

Le lun. 20 sept. 2021 à 15:00, Bastien ROUCARIES
<roucarie...@gmail.com> a écrit :
>

> Le lun. 20 sept. 2021 à 14:24, Ondrej Zary <ond...@zary.sk> a écrit :
> >
> > On Monday 20 September 2021, Bastien ROUCARIES wrote:
> > > Could you try to apply
> > >
> > > https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4

[kapouer][jonas] Do you think it could be backported using std::share_ptr ?

Superficially it seems semantic equivalent, but I am unease

Bastien

[Ondrej Zary]

On Monday 20 September 2021 16:56:18 Bastien ROUCARIES wrote:
> Le lun. 20 sept. 2021 à 14:24, Ondrej Zary <ond...@zary.sk> 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, unfortunately. There's no node_dir.cc file and also no BaseObjectPtr definition.
>
> Ok as band aid could you replace in the patch BaseObjectPtr by
> std:shared_ptr<ObjectPtr>

Biggest problem is the missing node_dir.cc file. The patched code from that file is not present at all in nodejs 10.

--
Ondrej Zary

[Bastien ROUCARIES]

According to https://github.com/nodejs/node/commit/b76a2e502c6f227f7df5f35ac3bbb0dcb2a8372d#diff-12768848757b514f1f042fddf06af34b9ba1d395113539ee98ff4bde165d1d4d

it is not needed in old nodejs because dir was not async...

[Bastien ROUCARIES]

Le lun. 20 sept. 2021 à 17:28, Jérémy Lal <kap...@melix.org> a écrit :

> Wild guess, try only that part:
>
> - delete wrap_;
> + wrap_->Detach();
> + wrap_.reset();
Yes but reset is std:shared_ptr<ObjectPtr>

But I agree it is the main part of the patch
> Jérémy
>

[Jérémy Lal]

Wild guess, try only that part:

- delete wrap_;
+ wrap_->Detach();
+ wrap_.reset();

Jérémy

[Jérémy Lal]

It's interesting to compare to

https://github.com/nodejs/node/commit/7f178663ebffc82c9f8a5a1b6bf2da0c263a30ed

somewhat shows what's "allowed" to do.

[Ondrej Zary]

Detach() is also not defined in src/base_object.h


--
Ondrej Zary

[Bastien ROUCARIES]

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 <ond...@zary.sk> a écrit :
>
>
>
> On Monday 20 September 2021 19:31:56 Bastien ROUCARIES wrote:
> > Le lun. 20 sept. 2021 à 17:28, Jérémy Lal <kap...@melix.org> a écrit :
> > >
> > >
> > >
> > > Le lun. 20 sept. 2021 à 19:15, Ondrej Zary <ond...@zary.sk> a écrit :
> > > >
> > > > On Monday 20 September 2021 16:56:18 Bastien ROUCARIES wrote:
> > > > > Le lun. 20 sept. 2021 à 14:24, Ondrej Zary <ond...@zary.sk> 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, unfortunately. There's no node_dir.cc file and also no BaseObjectPtr definition.
> > > > >
> > > > > Ok as band aid could you replace in the patch BaseObjectPtr by
> > > > > std:shared_ptr<ObjectPtr>
> > > >
> > > > Biggest problem is the missing node_dir.cc file. The patched code from that file is not present at all in nodejs 10.
> > >
> > > Wild guess, try only that part:
> > >
> > > - delete wrap_;
> > > + wrap_->Detach();
> > > + wrap_.reset();
> > Yes but reset is std:shared_ptr<ObjectPtr>
> >
> > But I agree it is the main part of the patch
>
> Detach() is also not defined in src/base_object.h
>
>
> --
> Ondrej Zary
>

[Ondrej Zary]

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 file node.gyp
Hunk #1 succeeded at 937 with fuzz 1 (offset -163 lines).
patching file src/base_object-inl.h
Hunk #1 FAILED at 32.
Hunk #2 succeeded at 50 (offset 1 line).
Hunk #3 FAILED at 58.
Hunk #4 succeeded at 78 (offset -2 lines).
Hunk #5 succeeded at 91 (offset -2 lines).
Hunk #6 succeeded at 138 with fuzz 1 (offset -16 lines).
2 out of 6 hunks FAILED -- saving rejects to file src/base_object-inl.h.rej
patching file src/base_object.h
Hunk #1 succeeded at 32 (offset 1 line).
Hunk #2 FAILED at 64.
Hunk #3 FAILED at 88.
Hunk #4 FAILED at 105.
Hunk #5 succeeded at 110 (offset -16 lines).
3 out of 5 hunks FAILED -- saving rejects to file src/base_object.h.rej
patching file src/env-inl.h
Hunk #1 FAILED at 1151.
1 out of 1 hunk FAILED -- saving rejects to file src/env-inl.h.rej
patching file src/env.cc
Hunk #1 succeeded at 412 with fuzz 2 (offset -19 lines).
Hunk #2 succeeded at 725 (offset -365 lines).
patching file src/env.h
Hunk #1 succeeded at 938 with fuzz 2 (offset -278 lines).
Hunk #2 FAILED at 1433.
1 out of 2 hunks FAILED -- saving rejects to file src/env.h.rej
patching file src/handle_wrap.cc
Hunk #1 FAILED at 84.
Hunk #2 succeeded at 111 (offset -11 lines).
1 out of 2 hunks FAILED -- saving rejects to file src/handle_wrap.cc.rej
patching file src/handle_wrap.h
Hunk #1 FAILED at 76.
1 out of 1 hunk FAILED -- saving rejects to file src/handle_wrap.h.rej
patching file src/memory_tracker-inl.h
Hunk #1 succeeded at 111 (offset -8 lines).
patching file src/memory_tracker.h
Hunk #1 succeeded at 29 (offset -1 lines).
Hunk #2 FAILED at 140.
1 out of 2 hunks FAILED -- saving rejects to file src/memory_tracker.h.rej
patching file test/cctest/node_test_fixture.h
Hunk #1 FAILED at 105.
1 out of 1 hunk FAILED -- saving rejects to file test/cctest/node_test_fixture.h.rej
patching file test/cctest/test_base_object_ptr.cc
patching file test/cctest/test_node_postmortem_metadata.cc
Hunk #1 succeeded at 91 (offset -2 lines).

--
Ondrej Zary

[Jérémy Lal]

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 (patched to support old uv).

Jérémy

[Ondrej Zary]

I've alrady tried installing it (stretch-backports), still segfaulted the same way.
Could rebuilding nodejs change anything?

--
Ondrej Zary

[Jérémy Lal]

That's scary - how come the same version of uv, used as a shared lib,

fails, while when compiled statically without the --shared-uv flag, succeeds ?

I need to see for myself... i'll try on a porter box.

[Ondrej Zary]

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,
from ../src/aliased_buffer.h:7,
from ../src/memory_tracker.h:12,
from ../src/memory_tracker-inl.h:6,
from ../src/base_object.h:27,
from ../src/async_wrap.h:27,
from ../src/async_wrap-inl.h:27,
from ../src/async_wrap.cc:22:
../src/util.h:210:11: error: ‘Persistent’ does not name a type; did you mean ‘gethostent’?
const Persistent<TypeName>& persistent);
^~~~~~~~~~


--
Ondrej Zary

[Bastien ROUCARIES]

Add on the top of the files using v8::Global;
and replace const Persistent<TypeName>& persistent by const
Global<Function>& persistent

> ^~~~~~~~~~
>
>
> --
> Ondrej Zary

[Ondrej Zary]

You probably mean Global<TypeName>& persistent.

Then ENVIRONMENT_STRONG_PERSISTENT_VALUES is undefined:
In file included from ../src/env-inl.h:28,
from ../src/base_object-inl.h:28,
from ../src/async_wrap-inl.h:28,
from ../src/async_wrap.cc:22:
../src/env.h:1036:40: error: ‘V’ has not been declared
ENVIRONMENT_STRONG_PERSISTENT_VALUES(V)
^
../src/env.h:1036:41: error: ISO C++ forbids declaration of ‘ENVIRONMENT_STRONG_PERSISTENT_VALUES’ with no type [-fpermissive]
ENVIRONMENT_STRONG_PERSISTENT_VALUES(V)
^
../src/env.h:1036:41: error: expected ‘;’ at end of member declaration
ENVIRONMENT_STRONG_PERSISTENT_VALUES(V)
^
;

--
Ondrej Zary

[Bastien ROUCARIES]

:S

Jeremy backport will be hard. If we use std::shared_ptr we leak memory

[Jérémy Lal]

Ok since i'm preparing a security update for node 10 i'm testing this issue.

- rebuilt nodejs 10.24.0 with the bundled libuv (1.34.2): it doesn't segfault anymore.

(and i'm not hallucinating here - it segfaults 100% without using bundled libuv).

- diffed bundled libuv with debian backport of libuv 1.34.2: they are the same

By mistake i looked at uv/src/win/fs.c and discovered that they do a much

better job at making sure multiple calls to uv_fs_req_cleanup(req) can't crash.

I really think this is the problem. I'm trying to fix it by protecting it from the nodejs side.

Jérémy