[Pkg-javascript-devel] Bug#1076350: simple way to reproduce segfault in nodejs when using browserify in i386
Сергей Сёмин
syominsergey at gmail.com
Thu Jul 18 12:17:41 BST 2024
I found a very simple way to reproduce segfault in nodejs when using browserify.
Take Debian Bookworm i386, upgraded in to last versions of packages
with this repos:
deb http://deb.debian.org/debian bookworm contrib main non-free-firmware
deb-src http://deb.debian.org/debian bookworm contrib main non-free-firmware
deb http://deb.debian.org/debian-security/ bookworm-security contrib
main non-free-firmware
deb-src http://deb.debian.org/debian-security/ bookworm-security
contrib main non-free-firmware
deb http://deb.debian.org/debian bookworm-updates contrib main non-free-firmware
deb-src http://deb.debian.org/debian bookworm-updates contrib main
non-free-firmware
Install node-browserify:
apt install node-browserify
In my case these packages were installed among others:
nodejs/stable,now 18.19.0+dfsg-6~deb12u2 i386 [installed,automatic]
node-browserify/stable,now 17.0.0+ds-5 all [installed]
We will use helloworld from official site https://browserify.org/, so
it is necessary also to install package node-uniq:
apt install node-uniq
Then create new folder called for example browserify_helloworld:
mkdir browserify_helloworld
Go into this folder:
cd browserify_helloworld
Create here new folder node_modules:
mkdir node_modules
Go into this folder:
cd node_modules
Create here symlink to folder with uniq module of nodejs:
ln -s /usr/share/nodejs/uniq
Go to level up:
cd ..
Create new file main.js with this content:
var unique = require('uniq');
var data = [1, 2, 2, 3, 4, 5, 5, 5, 6];
console.log(unique(data));
And call browserify:
browserify main.js -o bundle.js
Actual result is segfault, but it is not expected.
Install then gdb and systemd-coredump:
apt install gdb systemd-coredump
Repeat call of browserify script:
browserify main.js -o bundle.js
Actual unexpected result is segfault again. With core dumped.
Then run "coredumpctl debug" in console and bt command in gdb. Result
looks like this:
root at debian-bookworm-i386:~/browserify_helloworld# coredumpctl debug
PID: 7002 (node)
UID: 0 (root)
GID: 0 (root)
Signal: 11 (SEGV)
Timestamp: Thu 2024-07-18 13:43:32 MSK (8min ago)
Command Line: node /usr/bin/browserify main.js -o bundle.js
Executable: /usr/bin/node
Control Group: /user.slice/user-0.slice/session-1.scope
Unit: session-1.scope
Slice: user-0.slice
Session: 1
Owner UID: 0 (root)
Boot ID: fce3c1f6d57c4899a2db912dc3f41a2b
Machine ID: bb88a0eb919c40a690e344da5d477cfb
Hostname: debian-bookworm-i386
Storage: /var/lib/systemd/coredump/core.node.0.fce3c1f6d57c4899a2db912dc3f41a2b.7002.1721299412000000.zst
(present)
Size on Disk: 3.9M
Message: Process 7002 (node) of user 0 dumped core.
Stack trace of thread 7002:
#0 0x00000000b5858507 _ZN4node2fs9FSReqBaseD1Ev
(libnode.so.108 + 0x858507)
#1 0x00000000b5871a4d _ZN4node2fs13FSReqCallbackD0Ev
(libnode.so.108 + 0x871a4d)
#2 0x00000000b584bc52
_ZN4node24MakeLibuvRequestCallbackI7uv_fs_sPFvPS1_EE7WrapperES2_
(libnode.so.108 + 0x84bc52)
#3 0x00000000b7c4f620 n/a (libuv.so.1 + 0x9620)
#4 0x00000000b7c5324a n/a (libuv.so.1 + 0xd24a)
#5 0x00000000b7c6899b n/a (libuv.so.1 + 0x2299b)
#6 0x00000000b7c53c83 uv_run (libuv.so.1 + 0xdc83)
#7 0x00000000b577424a
_ZN4node13SpinEventLoopEPNS_11EnvironmentE (libnode.so.108 + 0x77424a)
#8 0x00000000b58a185c
_ZN4node16NodeMainInstance3RunEPiPNS_11EnvironmentE (libnode.so.108 +
0x8a185c)
#9 0x00000000b58a1cb9 _ZN4node16NodeMainInstance3RunEv
(libnode.so.108 + 0x8a1cb9)
#10 0x00000000b5807951
_ZN4node22LoadSnapshotDataAndRunEPPKNS_12SnapshotDataEPKNS_20InitializationResultE
(libnode.so.108 + 0x807951)
#11 0x00000000b580b70e _ZN4node5StartEiPPc
(libnode.so.108 + 0x80b70e)
#12 0x0000000000412087 main (node + 0x1087)
#13 0x00000000b7cbc2d5 __libc_start_call_main
(libc.so.6 + 0x232d5)
#14 0x00000000b7cbc398 __libc_start_main_impl
(libc.so.6 + 0x23398)
#15 0x00000000004120c7 _start (node + 0x10c7)
Stack trace of thread 7007:
#0 0x00000000b7eca559 __kernel_vsyscall
(linux-gate.so.1 + 0x559)
#1 0x00000000b7daebd2 __libc_do_syscall (libc.so.6 + 0x115bd2)
#2 0x00000000b7d1d5b5 __futex_abstimed_wait_common32
(libc.so.6 + 0x845b5)
#3 0x00000000b7d2080e __pthread_cond_wait_common
(libc.so.6 + 0x8780e)
#4 0x00000000b7c6269c uv_cond_wait (libuv.so.1 + 0x1c69c)
#5 0x00000000b58ce222 n/a (libnode.so.108 + 0x8ce222)
#6 0x00000000b7d2135d start_thread (libc.so.6 + 0x8835d)
#7 0x00000000b7dbc688 __clone3 (libc.so.6 + 0x123688)
Stack trace of thread 7005:
#0 0x00000000b7eca559 __kernel_vsyscall
(linux-gate.so.1 + 0x559)
#1 0x00000000b7daebd2 __libc_do_syscall (libc.so.6 + 0x115bd2)
#2 0x00000000b7d1d5b5 __futex_abstimed_wait_common32
(libc.so.6 + 0x845b5)
#3 0x00000000b7d2080e __pthread_cond_wait_common
(libc.so.6 + 0x8780e)
#4 0x00000000b7c6269c uv_cond_wait (libuv.so.1 + 0x1c69c)
#5 0x00000000b58ce222 n/a (libnode.so.108 + 0x8ce222)
#6 0x00000000b7d2135d start_thread (libc.so.6 + 0x8835d)
#7 0x00000000b7dbc688 __clone3 (libc.so.6 + 0x123688)
Stack trace of thread 7008:
#0 0x00000000b7eca559 __kernel_vsyscall
(linux-gate.so.1 + 0x559)
#1 0x00000000b7daebd2 __libc_do_syscall (libc.so.6 + 0x115bd2)
#2 0x00000000b7d1d5b5 __futex_abstimed_wait_common32
(libc.so.6 + 0x845b5)
#3 0x00000000b7d29912 do_futex_wait (libc.so.6 + 0x90912)
#4 0x00000000b7d299bb __new_sem_wait_slow64 (libc.so.6
+ 0x909bb)
#5 0x00000000b7c6272b uv_sem_wait (libuv.so.1 + 0x1c72b)
#6 0x00000000b597f6e3 n/a (libnode.so.108 + 0x97f6e3)
#7 0x00000000b7d2135d start_thread (libc.so.6 + 0x8835d)
#8 0x00000000b7dbc688 __clone3 (libc.so.6 + 0x123688)
Stack trace of thread 7009:
#0 0x00000000b7eca559 __kernel_vsyscall
(linux-gate.so.1 + 0x559)
#1 0x00000000b7daebd2 __libc_do_syscall (libc.so.6 + 0x115bd2)
#2 0x00000000b7d1d5b5 __futex_abstimed_wait_common32
(libc.so.6 + 0x845b5)
#3 0x00000000b7d2080e __pthread_cond_wait_common
(libc.so.6 + 0x8780e)
#4 0x00000000b7c6269c uv_cond_wait (libuv.so.1 + 0x1c69c)
#5 0x00000000b7c4ef5d n/a (libuv.so.1 + 0x8f5d)
#6 0x00000000b7d2135d start_thread (libc.so.6 + 0x8835d)
#7 0x00000000b7dbc688 __clone3 (libc.so.6 + 0x123688)
Stack trace of thread 7012:
#0 0x00000000b7eca559 __kernel_vsyscall
(linux-gate.so.1 + 0x559)
#1 0x00000000b7daebd2 __libc_do_syscall (libc.so.6 + 0x115bd2)
#2 0x00000000b7d1d5b5 __futex_abstimed_wait_common32
(libc.so.6 + 0x845b5)
#3 0x00000000b7d2080e __pthread_cond_wait_common
(libc.so.6 + 0x8780e)
#4 0x00000000b7c6269c uv_cond_wait (libuv.so.1 + 0x1c69c)
#5 0x00000000b7c4ef5d n/a (libuv.so.1 + 0x8f5d)
#6 0x00000000b7d2135d start_thread (libc.so.6 + 0x8835d)
#7 0x00000000b7dbc688 __clone3 (libc.so.6 + 0x123688)
Stack trace of thread 7004:
#0 0x00000000b7eca559 __kernel_vsyscall
(linux-gate.so.1 + 0x559)
#1 0x00000000b7daebd2 __libc_do_syscall (libc.so.6 + 0x115bd2)
#2 0x00000000b7d1d5b5 __futex_abstimed_wait_common32
(libc.so.6 + 0x845b5)
#3 0x00000000b7d2080e __pthread_cond_wait_common
(libc.so.6 + 0x8780e)
#4 0x00000000b7c6269c uv_cond_wait (libuv.so.1 + 0x1c69c)
#5 0x00000000b58ce222 n/a (libnode.so.108 + 0x8ce222)
#6 0x00000000b7d2135d start_thread (libc.so.6 + 0x8835d)
#7 0x00000000b7dbc688 __clone3 (libc.so.6 + 0x123688)
Stack trace of thread 7003:
#0 0x00000000b7eca559 __kernel_vsyscall
(linux-gate.so.1 + 0x559)
#1 0x00000000b7dbabc3 epoll_wait (libc.so.6 + 0x121bc3)
#2 0x00000000b7c68c8e n/a (libuv.so.1 + 0x22c8e)
#3 0x00000000b7c53c83 uv_run (libuv.so.1 + 0xdc83)
#4 0x00000000b58d3378
_ZZN4node23WorkerThreadsTaskRunner20DelayedTaskScheduler5StartEvENUlPvE_4_FUNES2_
(libnode.so.108 + 0x8d3378)
#5 0x00000000b7d2135d start_thread (libc.so.6 + 0x8835d)
#6 0x00000000b7dbc688 __clone3 (libc.so.6 + 0x123688)
Stack trace of thread 7011:
#0 0x00000000b7eca559 __kernel_vsyscall
(linux-gate.so.1 + 0x559)
#1 0x00000000b7daebd2 __libc_do_syscall (libc.so.6 + 0x115bd2)
#2 0x00000000b7d1d5b5 __futex_abstimed_wait_common32
(libc.so.6 + 0x845b5)
#3 0x00000000b7d2080e __pthread_cond_wait_common
(libc.so.6 + 0x8780e)
#4 0x00000000b7c6269c uv_cond_wait (libuv.so.1 + 0x1c69c)
#5 0x00000000b7c4ef5d n/a (libuv.so.1 + 0x8f5d)
#6 0x00000000b7d2135d start_thread (libc.so.6 + 0x8835d)
#7 0x00000000b7dbc688 __clone3 (libc.so.6 + 0x123688)
Stack trace of thread 7006:
#0 0x00000000b7eca559 __kernel_vsyscall
(linux-gate.so.1 + 0x559)
#1 0x00000000b7daebd2 __libc_do_syscall (libc.so.6 + 0x115bd2)
#2 0x00000000b7d1d5b5 __futex_abstimed_wait_common32
(libc.so.6 + 0x845b5)
#3 0x00000000b7d2080e __pthread_cond_wait_common
(libc.so.6 + 0x8780e)
#4 0x00000000b7c6269c uv_cond_wait (libuv.so.1 + 0x1c69c)
#5 0x00000000b58ce222 n/a (libnode.so.108 + 0x8ce222)
#6 0x00000000b7d2135d start_thread (libc.so.6 + 0x8835d)
#7 0x00000000b7dbc688 __clone3 (libc.so.6 + 0x123688)
Stack trace of thread 7010:
#0 0x00000000b7eca559 __kernel_vsyscall
(linux-gate.so.1 + 0x559)
#1 0x00000000b7daebd2 __libc_do_syscall (libc.so.6 + 0x115bd2)
#2 0x00000000b7d1d5b5 __futex_abstimed_wait_common32
(libc.so.6 + 0x845b5)
#3 0x00000000b7d2080e __pthread_cond_wait_common
(libc.so.6 + 0x8780e)
#4 0x00000000b7c6269c uv_cond_wait (libuv.so.1 + 0x1c69c)
#5 0x00000000b7c4ef5d n/a (libuv.so.1 + 0x8f5d)
#6 0x00000000b7d2135d start_thread (libc.so.6 + 0x8835d)
#7 0x00000000b7dbc688 __clone3 (libc.so.6 + 0x123688)
ELF object binary architecture: Intel 80386
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/node...
(No debugging symbols found in /usr/bin/node)
[New LWP 7002]
[New LWP 7007]
[New LWP 7005]
[New LWP 7008]
[New LWP 7009]
[New LWP 7012]
[New LWP 7004]
[New LWP 7003]
[New LWP 7011]
[New LWP 7006]
[New LWP 7010]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `node /usr/bin/browserify main.js -o bundle.js'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0xb5858507 in node::fs::FSReqBase::~FSReqBase() () from
/lib/i386-linux-gnu/libnode.so.108
[Current thread is 1 (Thread 0xb7b82780 (LWP 7002))]
(gdb) bt
#0 0xb5858507 in node::fs::FSReqBase::~FSReqBase() () from
/lib/i386-linux-gnu/libnode.so.108
#1 0xb5871a4d in node::fs::FSReqCallback::~FSReqCallback() () from
/lib/i386-linux-gnu/libnode.so.108
#2 0xb584bc52 in node::MakeLibuvRequestCallback<uv_fs_s, void
(*)(uv_fs_s*)>::Wrapper(uv_fs_s*) () from
/lib/i386-linux-gnu/libnode.so.108
#3 0xb7c4f620 in ?? () from /lib/i386-linux-gnu/libuv.so.1
#4 0xb7c5324a in ?? () from /lib/i386-linux-gnu/libuv.so.1
#5 0xb7c6899b in ?? () from /lib/i386-linux-gnu/libuv.so.1
#6 0xb7c53c83 in uv_run () from /lib/i386-linux-gnu/libuv.so.1
#7 0xb577424a in node::SpinEventLoop(node::Environment*) () from
/lib/i386-linux-gnu/libnode.so.108
#8 0xb58a185c in node::NodeMainInstance::Run(int*,
node::Environment*) () from /lib/i386-linux-gnu/libnode.so.108
#9 0xb58a1cb9 in node::NodeMainInstance::Run() () from
/lib/i386-linux-gnu/libnode.so.108
#10 0xb5807951 in node::LoadSnapshotDataAndRun(node::SnapshotData
const**, node::InitializationResult const*) () from
/lib/i386-linux-gnu/libnode.so.108
#11 0xb580b70e in node::Start(int, char**) () from
/lib/i386-linux-gnu/libnode.so.108
#12 0x00412087 in main ()
(gdb)
Backtrace in libnode.so is the same as earlier.
It is also possible to reproduce problem in same way in Debian Trixie
i386 with these versions of packages of interest installed:
Get:13 http://deb.debian.org/debian trixie/main i386 nodejs i386
20.15.0+dfsg-1 [344 kB]
Get:306 http://deb.debian.org/debian trixie/main i386 node-browserify
all 17.0.0+ds-5 [29.6 kB]
Unfortunately for some reasons I was unable to see bactrace because of
error on "coredumpctl debug" call:
PID: 8580 (node)
UID: 0 (root)
GID: 0 (root)
Signal: 11 (SEGV)
Timestamp: Thu 2024-07-18 14:02:51 MSK (5s ago)
Command Line: node /usr/bin/browserify main.js -o bundle.js
Executable: /usr/bin/node
Control Group: /user.slice/user-0.slice/user at 0.service/tmux-spawn-8d9909b4-b4ac-4d57-8ff1-8c9e05b7fa19.scope
Unit: user at 0.service
User Unit: tmux-spawn-8d9909b4-b4ac-4d57-8ff1-8c9e05b7fa19.scope
Slice: user-0.slice
Owner UID: 0 (root)
Boot ID: 3891d8b7f35b4e098e7abf16f714051d
Machine ID: bb88a0eb919c40a690e344da5d477cfb
Hostname: debian-trixie-i386
Storage: none
Message: Process 8580 (node) of user 0 terminated abnormally
without generating a coredump.
Coredump entry has no core attached (neither internally in the journal
nor externally on disk).
It is impossible to reproduce segfault in nodejs in Debian Trixie
amd64 in the same way even with same versions of packages as in Debian
Trixie i386:
Get:7 https://deb.debian.org/debian testing/main amd64 nodejs amd64
20.15.0+dfsg-1 [344 kB]
Get:300 https://deb.debian.org/debian testing/main amd64
node-browserify all 17.0.0+ds-5 [29.6 kB]
In Debian Trixie amd64 command "browserify main.js -o bundle.js" works
correctly and creates file bundle.js without segfault.
So it is really an i386 problem.
More information about the Pkg-javascript-devel
mailing list