> 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 -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
