> 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
