Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Le mar. 21 sept. 2021 à 08:46, Jérémy Lal a écrit : > > > Le mar. 21 sept. 2021 à 08:34, Ondrej Zary a écrit : > >> On Tuesday 21 September 2021, Jérémy Lal wrote: >> >> > Libuv1 1.34.2 - same version as the one in nodejs/deps/uv/ - is in >> > buster-backports. >> > It would be nice to try building against that version. >> > Some nodejs tests might fail (patched to support old uv). >> >> I've alrady tried installing it (stretch-backports), still segfaulted the >> same way. >> Could rebuilding nodejs change anything? >> > > 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. > 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
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Le mar. 21 sept. 2021 à 08:58, Ondrej Zary a écrit : > > On Tuesday 21 September 2021, Bastien ROUCARIES wrote: > > Le mar. 21 sept. 2021 à 07:55, Ondrej Zary a écrit : > > > > > > On Monday 20 September 2021, Bastien Roucariès wrote: > > > > Le lundi 20 septembre 2021, 19:32:52 UTC Bastien 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& persistent); > > > > Add on the top of the files using v8::Global; > > and replace const Persistent& persistent by const > > Global& persistent > > You probably mean Global& 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) :S Jeremy backport will be hard. If we use std::shared_ptr we leak memory
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
On Tuesday 21 September 2021, Bastien ROUCARIES wrote: > Le mar. 21 sept. 2021 à 07:55, Ondrej Zary a écrit : > > > > On Monday 20 September 2021, Bastien Roucariès wrote: > > > Le lundi 20 septembre 2021, 19:32:52 UTC Bastien ROUCARIES a écrit : > > > Could you try one by one the following 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& persistent); > > Add on the top of the files using v8::Global; > and replace const Persistent& persistent by const > Global& persistent You probably mean Global& 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
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Le mar. 21 sept. 2021 à 07:55, Ondrej Zary a écrit : > > On Monday 20 September 2021, Bastien Roucariès wrote: > > Le lundi 20 septembre 2021, 19:32:52 UTC Bastien ROUCARIES a écrit : > > Could you try one by one the following untested patch. Please compile and > > run > > the testsuite. > > The 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& persistent); Add on the top of the files using v8::Global; and replace const Persistent& persistent by const Global& persistent >^~ > > > -- > Ondrej Zary
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
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& persistent); ^~ -- Ondrej Zary
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Le mar. 21 sept. 2021 à 08:34, Ondrej Zary a écrit : > On Tuesday 21 September 2021, Jérémy Lal wrote: > > > Libuv1 1.34.2 - same version as the one in nodejs/deps/uv/ - is in > > buster-backports. > > It would be nice to try building against that version. > > Some nodejs tests might fail (patched to support old uv). > > I've alrady tried installing it (stretch-backports), still segfaulted the > same way. > Could rebuilding nodejs change anything? > 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.
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
On Tuesday 21 September 2021, Jérémy Lal wrote: > Le lun. 20 sept. 2021 à 22:30, Ondrej Zary a écrit : > > > On Monday 20 September 2021 21:32:52 Bastien ROUCARIES wrote: > > > Could you try first to apply > > https://github.com/nodejs/node/commit/c60780ff52 > > > > > > And see if the reject are 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). > > > > 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). I've alrady tried installing it (stretch-backports), still segfaulted the same way. Could rebuilding nodejs change anything? -- Ondrej Zary
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Le lun. 20 sept. 2021 à 22:30, Ondrej Zary a écrit : > On Monday 20 September 2021 21:32:52 Bastien ROUCARIES wrote: > > Could you try first to apply > https://github.com/nodejs/node/commit/c60780ff52 > > > > And see if the reject are bad ? > > Lots of failed hunks, I'll never get this to compile: > > $ 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). > 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
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
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
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
Could you try first to apply https://github.com/nodejs/node/commit/c60780ff52 And see if the reject are bad ? Bastien Le lun. 20 sept. 2021 à 19:15, Ondrej Zary a écrit : > > > > On Monday 20 September 2021 19:31:56 Bastien ROUCARIES wrote: > > Le lun. 20 sept. 2021 à 17:28, Jérémy Lal a écrit : > > > > > > > > > > > > Le lun. 20 sept. 2021 à 19:15, Ondrej Zary a écrit : > > > > > > > > On Monday 20 September 2021 16:56:18 Bastien ROUCARIES wrote: > > > > > Le lun. 20 sept. 2021 à 14:24, Ondrej Zary a écrit : > > > > > > > > > > > > On Monday 20 September 2021, Bastien ROUCARIES wrote: > > > > > > > Could you try to apply > > > > > > > > > > > > > > https://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 > > > > > > > > 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 > > > > But I agree it is the main part of the patch > > Detach() is also not defined in src/base_object.h > > > -- > Ondrej Zary > > -- > Pkg-javascript-devel mailing list > pkg-javascript-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
On Monday 20 September 2021 19:31:56 Bastien ROUCARIES wrote: > Le lun. 20 sept. 2021 à 17:28, Jérémy Lal a écrit : > > > > > > > > Le lun. 20 sept. 2021 à 19:15, Ondrej Zary a écrit : > > > > > > On Monday 20 September 2021 16:56:18 Bastien ROUCARIES wrote: > > > > Le lun. 20 sept. 2021 à 14:24, Ondrej Zary a écrit : > > > > > > > > > > On Monday 20 September 2021, Bastien ROUCARIES wrote: > > > > > > Could you try to apply > > > > > > > > > > > > https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4 > > > > > > > > > > > > I think it describe that you see > > > > > > > > > > Does not apply, 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 > > > > > > 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 > > But I agree it is the main part of the patch Detach() is also not defined in src/base_object.h -- Ondrej Zary
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Le lun. 20 sept. 2021 à 19:32, Bastien ROUCARIES < roucaries.bast...@gmail.com> a écrit : > Le lun. 20 sept. 2021 à 17:28, Jérémy Lal a écrit : > > > > > > > > Le lun. 20 sept. 2021 à 19:15, Ondrej Zary a écrit : > > > > > > On Monday 20 September 2021 16:56:18 Bastien ROUCARIES wrote: > > > > Le lun. 20 sept. 2021 à 14:24, Ondrej Zary a écrit > : > > > > > > > > > > On Monday 20 September 2021, Bastien ROUCARIES wrote: > > > > > > Could you try to apply > > > > > > > > > > > > > https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4 > > > > > > > > > > > > I think it describe that you see > > > > > > > > > > Does not apply, 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 > > > > > > 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 > > But I agree it is the main part of the patch > It's interesting to compare to https://github.com/nodejs/node/commit/7f178663ebffc82c9f8a5a1b6bf2da0c263a30ed somewhat shows what's "allowed" to do.
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Le lun. 20 sept. 2021 à 17:28, Jérémy Lal a écrit : > > > > Le lun. 20 sept. 2021 à 19:15, Ondrej Zary a écrit : > > > > On Monday 20 September 2021 16:56:18 Bastien ROUCARIES wrote: > > > Le lun. 20 sept. 2021 à 14:24, Ondrej Zary a écrit : > > > > > > > > On Monday 20 September 2021, Bastien 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 > > > > 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 But I agree it is the main part of the patch > Jérémy >
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Le lun. 20 sept. 2021 à 19:15, Ondrej Zary a écrit : > > On Monday 20 September 2021 16:56:18 Bastien ROUCARIES wrote: > > Le lun. 20 sept. 2021 à 14:24, Ondrej Zary a écrit : > > > > > > On Monday 20 September 2021, Bastien ROUCARIES wrote: > > > > Could you try to apply > > > > > > > > https://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 > > 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(); Jérémy
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
Le lun. 20 sept. 2021 à 17:15, Ondrej Zary a écrit : > > On Monday 20 September 2021 16:56:18 Bastien ROUCARIES wrote: > > Le lun. 20 sept. 2021 à 14:24, Ondrej Zary a écrit : > > > > > > On Monday 20 September 2021, Bastien ROUCARIES wrote: > > > > Could you try to apply > > > > > > > > https://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 > > Biggest problem is the missing node_dir.cc file. The patched code from that > file is not present at all in nodejs 10. According to https://github.com/nodejs/node/commit/b76a2e502c6f227f7df5f35ac3bbb0dcb2a8372d#diff-12768848757b514f1f042fddf06af34b9ba1d395113539ee98ff4bde165d1d4d it is not needed in old nodejs because dir was not async... Bastien > > -- > Ondrej Zary > > -- > Pkg-javascript-devel mailing list > pkg-javascript-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
On Monday 20 September 2021 16:56:18 Bastien ROUCARIES wrote: > Le lun. 20 sept. 2021 à 14:24, Ondrej Zary a écrit : > > > > On Monday 20 September 2021, Bastien ROUCARIES wrote: > > > Could you try to apply > > > > > > https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4 > > > > > > 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 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
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386
Le lun. 20 sept. 2021 à 15:00, Bastien ROUCARIES a écrit : > > Le lun. 20 sept. 2021 à 14:24, Ondrej Zary a écrit : > > > > On Monday 20 September 2021, Bastien ROUCARIES wrote: > > > Could you try to apply > > > > > > https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4 [kapouer][jonas] Do you think it could be backported using std::share_ptr ? Superficially it seems semantic equivalent, but I am unease Bastien > > > > > > 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 > > Bastien > > > > -- > > Ondrej Zary > > > > -- > > Pkg-javascript-devel mailing list > > pkg-javascript-de...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel > > -- > Pkg-javascript-devel mailing list > pkg-javascript-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386
Le lun. 20 sept. 2021 à 14:24, Ondrej Zary a écrit : > > On Monday 20 September 2021, Bastien ROUCARIES wrote: > > Could you try to apply > > > > https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4 > > > > I think it describe that you see > > Does not apply, 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 Bastien > -- > Ondrej Zary > > -- > Pkg-javascript-devel mailing list > pkg-javascript-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
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
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
Could you try to apply https://github.com/nodejs/node/commit/aa4611cccbcb197df51a9f7056d019005d91acf4 I think it describe that you see Bastien Le lun. 20 sept. 2021 à 12:51, Ondrej Zary a écrit : > > > Ok are you on IRC ? I am as rouca on #debian-js channel > > No, I'm not. > > > Install the 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::allocator >, std::allocator std::char_traits, std::allocator > > > const&, > std::vector, > std::allocator >, std::allocator std::char_traits, std::allocator > > > 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::allocator >, std::allocator std::char_traits, std::allocator > > > const&, > std::vector, > std::allocator >, std::allocator std::char_traits, std::allocator > > > 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 >
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
> 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::allocator >, std::allocator, std::allocator > > > const&, std::vector, std::allocator >, std::allocator, std::allocator > > > 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::allocator >, std::allocator, std::allocator > > > const&, std::vector, std::allocator >, std::allocator, std::allocator > > > 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
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386
Ok are you on IRC ? I am as rouca on #debian-js channel Install the debug symbols of nodejs and libuv (if available) and try to run valgrind with --smc-check=all --read-var-info=yes --track-origins=yes Bastien Le lun. 20 sept. 2021 à 11:57, Ondrej Zary a écrit : > > > And try to rebuild the whole libuv and nodejs with -fstack-protector-all > > Does not print anything other than Segmentation fault. > > -- > Ondrej Zary > > -- > Pkg-javascript-devel mailing list > pkg-javascript-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
> And try to rebuild the whole libuv and nodejs with -fstack-protector-all Does not print anything other than Segmentation fault. -- Ondrej Zary
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
> 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::allocator >, std::allocator, std::allocator > > > const&, std::vector, std::allocator >, std::allocator, std::allocator > > > 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::allocator >, std::allocator, std::allocator > > > const&, std::vector, std::allocator >, std::allocator, std::allocator > > > 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
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
On Monday 20 September 2021, Bastien ROUCARIES wrote: > Could you try to build both libuv and node with -fsanitize=null it is > likely a null dereference so catch it It does not seem to work correctly: runuser -u gitlab -- sh -c 'yarnpkg install' ../deps/v8/src/date.cc:44:20: runtime error: member call on null pointer of type 'struct Smi' ../deps/v8/src/date.cc:47:40: runtime error: member call on null pointer of type 'struct Smi' ../deps/v8/src/heap/heap-inl.h:319:30: runtime error: member call on null pointer of type 'struct Object' ../deps/v8/src/objects.h:1621:16: runtime error: member call on null pointer of type 'const struct Object' ../deps/v8/src/heap/heap-inl.h:319:30: runtime error: member call on null pointer of type 'struct Object' ../deps/v8/src/objects.h:1621:16: runtime error: member call on null pointer of type 'const struct Object' ../deps/v8/src/heap/heap-inl.h:324:42: runtime error: member call on null pointer of type 'struct MaybeObject' ../deps/v8/src/objects/maybe-object-inl.h:37:12: runtime error: member call on null pointer of type 'struct MaybeObject' ../deps/v8/src/heap/heap-inl.h:319:30: runtime error: member call on null pointer of type 'struct Object' ../deps/v8/src/objects.h:1621:16: runtime error: member call on null pointer of type 'const struct Object' ../deps/v8/src/heap/heap-inl.h:319:30: runtime error: member call on null pointer of type 'struct Object' ../deps/v8/src/objects.h:1621:16: runtime error: member call on null pointer of type 'const struct Object' ../deps/v8/src/heap/heap-inl.h:324:42: runtime error: member call on null pointer of type 'struct MaybeObject' ../deps/v8/src/objects/maybe-object-inl.h:37:12: runtime error: member call on null pointer of type 'struct MaybeObject' ../deps/v8/src/objects-inl.h:924:71: runtime error: member call on null pointer of type 'const struct Smi' ../deps/v8/src/objects-inl.h:924:71: runtime error: member call on null pointer of type 'const struct Smi' ../deps/v8/src/objects-inl.h:924:71: runtime error: member call on null pointer of type 'const struct Smi' ../deps/v8/src/objects-inl.h:924:71: runtime error: member call on null pointer of type 'const struct Smi' ../deps/v8/src/objects-inl.h:924:71: runtime error: member call on null pointer of type 'const struct Smi' ../deps/v8/src/objects.cc:13257:30: runtime error: member call on null pointer of type 'struct Object' ../deps/v8/src/objects-inl.h:178:1: runtime error: member call on null pointer of type 'const struct Object' ../deps/v8/src/objects.h:1621:16: runtime error: member call on null pointer of type 'const struct Object' ../deps/v8/src/objects.cc:13261:49: runtime error: member call on null pointer of type 'struct Object' ../deps/v8/src/objects-inl.h:555:15: runtime error: member call on null pointer of type 'const struct Object' ../deps/v8/src/objects-inl.h:556:77: runtime error: member call on null pointer of type 'const struct Smi' ../deps/v8/src/objects-inl.h:924:71: runtime error: member call on null pointer of type 'const struct Smi' ../deps/v8/src/objects-inl.h:924:71: runtime error: member call on null pointer of type 'const struct Smi' ../deps/v8/src/objects-inl.h:924:71: runtime error: member call on null pointer of type 'const struct Smi' ../deps/v8/src/objects-inl.h:924:71: runtime error: member call on null pointer of type 'const struct Smi' ../deps/v8/src/heap/heap-inl.h:540:40: runtime error: member call on null pointer of type 'struct Smi' ../deps/v8/src/objects.cc:10170:70: runtime error: member call on null pointer of type 'struct Object' ../deps/v8/src/objects-inl.h:178:1: runtime error: member call on null pointer of type 'const struct Object' ../deps/v8/src/objects.h:1621:16: runtime error: member call on null pointer of type 'const struct Object' ../deps/v8/src/objects-inl.h:924:71: runtime error: member call on null pointer of type 'const struct Smi' ../deps/v8/src/objects/fixed-array-inl.h:275:17: runtime error: member call on null pointer of type 'struct Object' ../deps/v8/src/objects/fixed-array-inl.h:282:27: runtime error: member call on null pointer of type 'struct Object' ../deps/v8/src/objects-inl.h:64:22: runtime error: member call on null pointer of type 'struct Smi' ../deps/v8/src/heap/heap-inl.h:319:30: runtime error: member call on null pointer of type 'struct Object' ../deps/v8/src/objects.h:1621:16: runtime error: member call on null pointer of type 'const struct Object' ../deps/v8/src/objects-inl.h:924:71: runtime error: member call on null pointer of type 'const struct Smi' ../deps/v8/src/objects-inl.h:924:71: runtime error: member call on null pointer of type 'const struct Smi' ../deps/v8/src/objects-inl.h:924:71: runtime error: member call on null pointer of type 'const struct Smi' ../deps/v8/src/objects-inl.h:924:71: runtime error: member call on null pointer of type 'const struct Smi' ../deps/v8/src/address-map.cc:20:28: runtime error: member call on null pointer of type 'struct
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
Le lun. 20 sept. 2021 à 10:39, Ondrej Zary a écrit : > > > Ok now try to run the whole thing against valgrind... > Seems that valgrind does not work with asan: > > $ LD_PRELOAD=/usr/lib/i386-linux-gnu/libasan.so.5.0.0 valgrind yarnpkg install > ==752== Memcheck, a memory error detector > ==752== 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::allocator >, std::allocator std::char_traits, std::allocator > > > const&, > std::vector, > std::allocator >, std::allocator std::char_traits, std::allocator > > > 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::allocator >, std::allocator std::char_traits, std::allocator > > > const&, > std::vector, > std::allocator >, std::allocator std::char_traits, std::allocator > > > 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:
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
> 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::allocator >, std::allocator, std::allocator > > > const&, std::vector, std::allocator >, std::allocator, std::allocator > > > 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::allocator >, std::allocator, std::allocator > > > const&, std::vector, std::allocator >, std::allocator, std::allocator > > > 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==
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
Le lun. 20 sept. 2021 à 10:20, Bastien ROUCARIES a écrit : > > Le lun. 20 sept. 2021 à 10:15, Ondrej Zary a écrit : > > > > libuv libuv1:i386 1.24.1-1+deb10u1 with -fsanitize=address,undefined: > > > > yarn install v1.13.0 > > [1/5] Validating package.json... > > [2/5] Resolving packages... > > [3/5] Fetching packages... > > [---] > > 0/520AddressSanitizer:DEADLYSIGNAL > > = > > ==26662==ERROR: AddressSanitizer: SEGV on unknown address 0x1085 (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::allocator >, std::allocator > std::char_traits, std::allocator > > > const&, > > std::vector, > > std::allocator >, std::allocator > std::char_traits, std::allocator > > > 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 > Ok now try to run the whole thing against valgrind... Could you try to build both libuv and node with -fsanitize=null it is likely a null dereference so catch it Bastien > > Bastien > > > > > > > -- > > Ondrej Zary > > > > -- > > Pkg-javascript-devel mailing list > > pkg-javascript-de...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
Le lun. 20 sept. 2021 à 10:15, Ondrej Zary a écrit : > > libuv libuv1:i386 1.24.1-1+deb10u1 with -fsanitize=address,undefined: > > yarn install v1.13.0 > [1/5] Validating package.json... > [2/5] Resolving packages... > [3/5] Fetching packages... > [---] > 0/520AddressSanitizer:DEADLYSIGNAL > = > ==26662==ERROR: AddressSanitizer: SEGV on unknown address 0x1085 (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::allocator >, std::allocator std::char_traits, std::allocator > > > const&, > std::vector, > std::allocator >, std::allocator std::char_traits, std::allocator > > > 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 Ok now try to run the whole thing against valgrind... Bastien > > > -- > Ondrej Zary > > -- > Pkg-javascript-devel mailing list > pkg-javascript-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
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 0x1085 (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::allocator >, std::allocator, std::allocator > > > const&, std::vector, std::allocator >, std::allocator, std::allocator > > > 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
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Le lun. 20 sept. 2021 à 12:02, Ondrej Zary a écrit : > I'm unable to compile node with -fsanitize=address,undefined. Seems that > compiler hits 32-bit memory space limit: > cc1plus: out of memory allocating 65536 bytes after a total of 3356393472 > bytes > Libuv only will be Nice Node is not crosscompile safe so this is a dead end > > -- > Ondrej Zary >
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
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
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Le lun. 20 sept. 2021 à 08:02, Ondrej Zary a écrit : > > Rebuilt Debian libuv1 1.24.1 with -fno-stack-protector - still segfaults. > Rebuilt Debian libuv1 1.42.0 (from unstable) in Buster - still segfaults. Please rebuild both nodejs and libuv with asan (adresse sanitizer) After, I think it is time to escalade. Bastien > -- > Ondrej Zary
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
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
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386
Le dim. 19 sept. 2021 à 21:57, Bastien ROUCARIES a écrit : > > try to pass > -fstack-protector-strong to the local version as cflags > > If it fail upstream does not take in acount stack protector > > Le dim. 19 sept. 2021 à 21:45, Bastien ROUCARIES > a écrit : > > > > Le dim. 19 sept. 2021 à 21:39, Bastien ROUCARIES > > a écrit : > > > > > > Le dim. 19 sept. 2021 à 21:36, Ondrej Zary a écrit : > > > > > > > > I've reinstalled nodejs and libnode64 back to original Buster > > > > 10.24.0~dfsg-1~deb10u1 and upgraded libuv1 to > > > > libuv1_1.34.2-1~bpo9+1_i386.deb from http://snapshot.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 > > > > -- > > > > Pkg-javascript-devel mailing list > > > > pkg-javascript-de...@alioth-lists.debian.net > > > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel > > > > -- > > Pkg-javascript-devel mailing list > > pkg-javascript-de...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel > > -- > Pkg-javascript-devel mailing list > pkg-javascript-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386
try to pass -fstack-protector-strong to the local version as cflags If it fail upstream does not take in acount stack protector Le dim. 19 sept. 2021 à 21:45, Bastien ROUCARIES a écrit : > > Le dim. 19 sept. 2021 à 21:39, Bastien ROUCARIES > a écrit : > > > > Le dim. 19 sept. 2021 à 21:36, Ondrej Zary a écrit : > > > > > > I've reinstalled nodejs and libnode64 back to original Buster > > > 10.24.0~dfsg-1~deb10u1 and upgraded libuv1 to > > > libuv1_1.34.2-1~bpo9+1_i386.deb from http://snapshot.debian.org > > > > > > It still segfaults! > > > > > > So it seems that the problem is not 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 > > > > > > -- > > > Pkg-javascript-devel mailing list > > > pkg-javascript-de...@alioth-lists.debian.net > > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel > > -- > Pkg-javascript-devel mailing list > pkg-javascript-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
Le dim. 19 sept. 2021 à 21:39, Bastien ROUCARIES a écrit : > > Le dim. 19 sept. 2021 à 21:36, Ondrej Zary a écrit : > > > > I've reinstalled nodejs and libnode64 back to original Buster > > 10.24.0~dfsg-1~deb10u1 and upgraded libuv1 to > > libuv1_1.34.2-1~bpo9+1_i386.deb from http://snapshot.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 > > > > -- > > Pkg-javascript-devel mailing list > > pkg-javascript-de...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
Le dim. 19 sept. 2021 à 21:36, Ondrej Zary a écrit : > > I've reinstalled nodejs and libnode64 back to original Buster > 10.24.0~dfsg-1~deb10u1 and upgraded libuv1 to libuv1_1.34.2-1~bpo9+1_i386.deb > from http://snapshot.debian.org > > It still segfaults! > > So it seems that the problem is not libuv version but its linking (included > in node or external). Or cflags? Or ldflags Could you dump the cflags/ldfalgs of both version? > > -- > Ondrej Zary > > -- > Pkg-javascript-devel mailing list > pkg-javascript-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
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
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386
Le dim. 19 sept. 2021 à 21:25, Bastien ROUCARIES a écrit : > > Le dim. 19 sept. 2021 à 21:15, Ondrej Zary a écrit : > > > > Added back --shared-zlib: works. > > Added back also --shared-cares: works. > > > > So you're right: --shared-libuv is the problem. > > Upstream seems to include libuv 1.34.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 > > > -- > > Ondrej Zary > > > > -- > > Pkg-javascript-devel mailing list > > pkg-javascript-de...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386
Le dim. 19 sept. 2021 à 21:15, Ondrej Zary a écrit : > > Added back --shared-zlib: works. > Added back also --shared-cares: works. > > So you're right: --shared-libuv is the problem. > Upstream seems to include libuv 1.34.2. > Buster has 1.24.1-1. Do you have valgrind ? If so and if it work (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 > > -- > Pkg-javascript-devel mailing list > pkg-javascript-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386
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
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: Bug#922075: npm: segfault during extract on i386
Le dim. 19 sept. 2021 à 20:21, Ondrej Zary a écrit : > > On Sunday 19 September 2021 20:13:47 Bastien ROUCARIES wrote: > > Hi, > > > > So you work on oldstable. > > > > Could you check for stable/testing/unstable/experimental ? And mark > > the bug with found /not found. > > Unfortunately I can't. 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! begin whith shared-uv Bastien > > Going to narrow it down. > > -- > Ondrej Zary > > -- > Pkg-javascript-devel mailing list > pkg-javascript-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
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
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
Le dim. 19 sept. 2021 à 19:37, Jérémy Lal a écrit : > > > > Le dim. 19 sept. 2021 à 20:18, Bastien ROUCARIES > a écrit : >> >> Hi, >> >> So you work on oldstable. >> >> Could you check for stable/testing/unstable/experimental ? And mark >> the bug with found /not found. >> > > Interestingly, the 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. I was more thinking about a cflags like hardening flags or something like this... Bastien > Jérémy
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
Le dim. 19 sept. 2021 à 20:18, Bastien ROUCARIES < roucaries.bast...@gmail.com> a écrit : > Hi, > > So you work on oldstable. > > Could you check for stable/testing/unstable/experimental ? And mark > the bug with found /not found. > > Interestingly, the copy of zlib in nodejs source has several 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
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
Hi, So you work on oldstable. Could you check for stable/testing/unstable/experimental ? And mark the bug with found /not found. Thanks Bastien Le dim. 19 sept. 2021 à 18:03, Ondrej Zary a écrit : > > There's no such patch in 10.24.0~dfsg-1~deb10u1 > > -- > Ondrej Zary
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
There's no such patch in 10.24.0~dfsg-1~deb10u1 -- Ondrej Zary
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
Le dim. 19 sept. 2021 à 17:40, Ondrej Zary a écrit : > > Upstream node rebuilt in Debian works. So it's not a compiler or libc problem. Does removing the debian patch large_pages_assembly_gnu_stack.patch Changes something ? Bastien > The Debian (buster) i386 version 10.24.0~dfsg-1~deb10u1 already contains SSE2 > instructions - it does not work on Pentium 3: > $ node > Illegal instruction > > So I doubt that changing -march would help. > > -- > Ondrej Zary
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
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
Bug#922075: [Pkg-javascript-devel] Bug#922075: Bug#922075: npm: segfault during extract on i386
Le dim. 19 sept. 2021 à 16:33, Ondrej Zary a écrit : > > upstream (strings in bin/node), seems to be statically linked: > gcc 6.3.1 > libc 2.17 according to https://github.com/nodejs/unofficial-builds/ > build log found at > https://unofficial-builds.nodejs.org/logs/202102231620-v10.24.0/x86.log > > 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. Could you try aurel32 tips: rouca: it's not obviously linked to libc [16:34] 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 Bastien > > -- > Ondrej Zary > > -- > Pkg-javascript-devel mailing list > pkg-javascript-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
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
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Le dim. 19 sept. 2021 à 15:48, Ondrej Zary a écrit : > > Seems that only Debian i386 build of nodejs is broken. > > Downloaded > https://unofficial-builds.nodejs.org/download/release/v10.24.0/node-v10.24.0-linux-x86.tar.xz > unpacked somewhere and edited /usr/bin/yarnpkg to point to the new bin/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! 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-javascript-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#922075: npm: segfault during extract on i386
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
Bug#922075: npm: segfault during extract on i386
It works from amd64 chroot on the same machine. The i386 nodejs is broken. -- Ondrej Zary
Bug#922075: npm: segfault during extract on i386
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::allocator >, #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>: mov0x8(%ebp),%esi 0xf6fdfb18 <+8>: call 0xf6f4d7e0 0xf6fdfb1d <+13>:add$0xfb8daf,%ebx 0xf6fdfb23 <+19>:mov0x14240(%ebx),%eax 0xf6fdfb29 <+25>:add$0x8,%eax 0xf6fdfb2c <+28>:mov%eax,(%esi) 0xf6fdfb2e <+30>:mov0x168(%esi),%eax 0xf6fdfb34 <+36>:test %eax,%eax 0xf6fdfb36 <+38>:je 0xf6fdfb4e <_ZN4node2fs9FSReqWrapD0Ev+62> 0xf6fdfb38 <+40>:lea0x16c(%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 0xf6fdfb4b <+59>:add$0x10,%esp 0xf6fdfb4e <+62>:mov0x14c(%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>:mov0x16ec8(%ebx),%eax 0xf6fdfb6a <+90>:mov0x4(%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>: mov0x20(%esi),%edx 0xf6fdfb79 <+105>: mov0x24(%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>: lea0x0(%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
Bug#922075: npm: segfault during extract on i386
Package: nodejs Version: 12.22.5~dfsg-2~11u1 Followup-For: Bug #922075 X-Debbugs-Cc: kexybisc...@outlook.com Dear Maintainer, I met this problem too on latest stable system, minimal repro and backtrace at https://pastebin.aosc.io/paste/INsQkzMR6S1sSnh3mLT47g . -- System Information: Debian 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
Bug#922075: npm: segfault during extract on i386
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 ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#922075: npm: segfault during extract on i386
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-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.98-1 (2020-01-26)
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Le ven. 5 avr. 2019 à 18:31, Bernhard Übelacker a écrit : > Hello Jérémy, > sorry for the delay. > > > > So if i run qemu with the first P6 cpu that comes to mind, pentiumpro, > > npm install electron-spellchecker@1.1.2 > > no longer crashes. > > > > That doesn't prove there is no crash on a 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 > >
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Hello Jérémy, sorry for the delay. > So if i run qemu with the first P6 cpu that comes to mind, pentiumpro, > npm install electron-spellchecker@1.1.2 > no longer crashes. > > That doesn't prove there is no crash on a supported cpu, but that's a start. > Comparing the flags and address sizes might 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) 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. 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 debugging_4.txt.gz Description: application/gzip
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Le ven. 29 mars 2019 à 14:22, Bernhard Übelacker a écrit : > Hello Jérémy, > > Am 29.03.19 um 12:44 schrieb Jérémy Lal: > > This fails too: > > yarnpkg add electron-spellchecker@1.1.2 > > > > Are you all doing this on qemu or on real hardware ? > > On i686 ? > > I'm asking because buster does not 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-spellchecker@1.1.2 no longer crashes. That doesn't prove there is no crash on a supported cpu, but that's a start. Comparing the flags and address sizes might help. Also upstream nodejs does not support 32bit cpu on linux platform. Jérémy 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, > CPU min MHz: 1000, > 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 >
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Hello Jérémy, Am 29.03.19 um 12:44 schrieb Jérémy Lal: > This fails too: > yarnpkg add electron-spellchecker@1.1.2 > > Are you all doing this on qemu or on real hardware ? > On i686 ? > I'm asking because buster does not support i586, nor does nodejs, > and it seems qemu defaults to something < 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, CPU min MHz: 1000, 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
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Control: reassign -1 nodejs This fails too: yarnpkg add electron-spellchecker@1.1.2 Are you all doing this on qemu or on real hardware ? On i686 ? I'm asking because buster does not support i586, nor does nodejs, and it seems qemu defaults to something < i686 (to be verified). Jérémy
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Le jeu. 28 mars 2019 à 11:58, Bernhard Übelacker a écrit : > Hello Jérémy Lal, > unfortunately yes, it still crashes. > > Attached file shows a test starting with a minimal up-to-date > Buster i386 qemu VM, and as far as I see after the crash > /usr/local/lib/node_modules does not exist and 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 looks right. I'm setting up a i386 qemu vm as well, maybe i'll find what's going on. Jérémy
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
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 # Buster i386 qemu VM 2019-03-28 apt update apt dist-upgrade apt install systemd-coredump npm benutzer@debian:~$ dpkg -l | grep gyp ii gyp 0.1+20180428git4d467626-3 all Cross-platform build script generator ii node-gyp 3.8.0-6 all Native addon build tool for Node.js benutzer@debian:~$ LANG=C ls -lisah ./node_modules ls: cannot access './node_modules': No such file or directory benutzer@debian:~$ LANG=C ls -lisah ./.npm ls: cannot access './.npm': No such file or directory benutzer@debian:~$ LANG=C ls -lisah /usr/local/lib/node_modules ls: cannot access '/usr/local/lib/node_modules': No such file or directory benutzer@debian:~$ npm --verbose install electron-spellchecker@1.1.2 npm info it worked if it ends with ok npm WARN npm npm does not support Node.js v10.15.2 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-spellchecker@1.1.2' ] npm info using npm@5.8.0 npm info using node@v10.15.2 npm verb config Skipping project config: /home/benutzer/.npmrc. (matches userconfig) npm verb npm-session a34f421692981832 npm http fetch GET 200 https://registry.npmjs.org/electron-spellchecker 210ms npm http fetch GET 200 https://registry.npmjs.org/electron-spellchecker/-/electron-spellchecker-1.1.2.tgz 52ms npm http fetch GET 200 https://registry.npmjs.org/mkdirp 72ms npm http fetch GET 200 https://registry.npmjs.org/electron-remote 84ms npm http fetch GET 200 https://registry.npmjs.org/keyboard-layout 88ms npm http fetch GET 200 https://registry.npmjs.org/bcp47 94ms npm http fetch GET 200 https://registry.npmjs.org/debug 95ms npm http fetch GET 200 https://registry.npmjs.org/lru-cache 107ms npm http fetch GET 200 https://registry.npmjs.org/pify 107ms npm http fetch GET 200 https://registry.npmjs.org/mkdirp/-/mkdirp-0.5.1.tgz 38ms npm http fetch GET 200 https://registry.npmjs.org/rxjs-serial-subscription 31ms npm http fetch GET 200 https://registry.npmjs.org/debug/-/debug-2.6.9.tgz 51ms npm http fetch GET 200 https://registry.npmjs.org/spawn-rx 39ms npm http fetch GET 200 https://registry.npmjs.org/pify/-/pify-2.3.0.tgz 49ms npm http fetch GET 200 https://registry.npmjs.org/spawn-rx/-/spawn-rx-2.0.12.tgz 49ms npm http fetch GET 200 https://registry.npmjs.org/rxjs 192ms npm http fetch GET 200 https://registry.npmjs.org/@paulcbetts%2fspellchecker 879ms npm http fetch GET 200 https://registry.npmjs.org/@paulcbetts%2fcld 1007ms npm http fetch GET 200 https://registry.npmjs.org/nan 51ms npm http fetch GET 200 https://registry.npmjs.org/rimraf 54ms npm http fetch GET 200 https://registry.npmjs.org/glob 57ms npm http fetch GET 200 https://registry.npmjs.org/underscore 90ms npm http fetch GET 200 https://registry.npmjs.org/glob/-/glob-5.0.15.tgz 35ms npm http fetch GET 200 https://registry.npmjs.org/path-is-absolute 41ms npm http fetch GET 200 https://registry.npmjs.org/inherits 43ms npm http fetch GET 200 https://registry.npmjs.org/inflight 45ms npm http fetch GET 200 https://registry.npmjs.org/once 45ms npm http fetch GET 200 https://registry.npmjs.org/minimatch 47ms npm http fetch GET 200 https://registry.npmjs.org/path-is-absolute/-/path-is-absolute-1.0.1.tgz 33ms npm http fetch GET 200 https://registry.npmjs.org/wrappy 23ms npm http fetch GET 200 https://registry.npmjs.org/brace-expansion 59ms npm http fetch GET 200 https://registry.npmjs.org/concat-map 27ms npm http fetch GET 200 https://registry.npmjs.org/balanced-match 30ms npm http fetch GET 200 https://registry.npmjs.org/fs.realpath 56ms npm http fetch GET 200 https://registry.npmjs.org/ms 30ms npm http fetch GET 200 https://registry.npmjs.org/ms/-/ms-2.0.0.tgz 24ms npm http fetch GET 200 https://registry.npmjs.org/xmlhttprequest 34ms npm http fetch GET 200 https://registry.npmjs.org/lodash.get 36ms npm http fetch GET 200 https://registry.npmjs.org/hashids 38ms npm http fetch GET 200 https://registry.npmjs.org/symbol-observable 26ms npm http fetch GET 200 https://registry.npmjs.org/event-kit 33ms npm http fetch GET 200
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Le jeu. 28 mars 2019 à 00:51, Bernhard Übelacker a écrit : > Hello Everyone, > I tried to track down when this crash got introduced into testing. > Can you check it still crashes with node-gyp 3.8.0-6 (#921625), while making sure it's not a locally installed copy that is used from ./node_modules/gyp or /usr/local/lib/node_modules. Thanks !
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
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::operator()
(this=0x8e12b5c, __ptr=0x1085) at /usr/include/c++/8/bits/unique_ptr.h:347
#1 std::unique_ptr >::~unique_ptr
(this=0x8e12b5c, __in_chrg=) at
/usr/include/c++/8/bits/unique_ptr.h:274
#2 node::fs::FSReqBase::~FSReqBase (this=0x8e12a10, __in_chrg=)
at ../src/node_file.h:66
#3 node::fs::FSReqWrap::~FSReqWrap (this=0x8e12a10, __in_chrg=)
at ../src/node_file.h:130
#4 node::fs::FSReqWrap::~FSReqWrap (this=0x8e12a10, __in_chrg=)
at ../src/node_file.h:130
#5 0xb6f384b3 in node::fs::FSReqAfterScope::~FSReqAfterScope (this=0xbffe2764,
__in_chrg=) 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 ) at
src/threadpool.c:313
#8 0xb6a0b77e in uv__async_io (loop=0xb6a2d1a0 ,
w=, events=) at src/unix/async.c:118
#9 0xb6a1b468 in uv__io_poll (loop=, timeout=)
at src/unix/linux-core.c:378
#10 0xb6a0c146 in uv_run (loop=0xb6a2d1a0 ,
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=) at ../src/node.cc:2969
#13 node::Start (argc=5, argv=) at ../src/node.cc:3029
#14 0x08049158 in main (argc=5, argv=0xbffe6574) at ../src/node_main.cc:124
# Buster i386 qemu VM 2019-03-27
apt update
apt dist-upgrade
apt install systemd-coredump gdb valgrind npm nodejs-dbgsym libnode64-dbgsym
libuv1-dbgsym
##
benutzer@debian:~$ npm --verbose install electron-spellchecker@1.1.2
npm info it worked if it ends with ok
npm WARN npm npm does not support Node.js v10.15.2
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-spellchecker@1.1.2' ]
npm info using npm@5.8.0
npm info using node@v10.15.2
npm verb config Skipping project config: /home/benutzer/.npmrc. (matches
userconfig)
npm verb npm-session 726ed65bca256027
npm http fetch GET 200 https://registry.npmjs.org/electron-spellchecker 845ms
npm http fetch GET 200
https://registry.npmjs.org/electron-spellchecker/-/electron-spellchecker-1.1.2.tgz
995ms
npm http fetch GET 200 https://registry.npmjs.org/bcp47 82ms
npm http fetch GET 200 https://registry.npmjs.org/mkdirp 78ms
npm http fetch GET 200 https://registry.npmjs.org/lru-cache 81ms
npm http fetch GET 200 https://registry.npmjs.org/pify 82ms
npm http fetch GET 200 https://registry.npmjs.org/debug 94ms
npm http fetch GET 200 https://registry.npmjs.org/rxjs 100ms
npm http fetch GET 200 https://registry.npmjs.org/debug/-/debug-2.6.9.tgz 48ms
npm http fetch GET 200 https://registry.npmjs.org/spawn-rx 42ms
npm http fetch GET 200 https://registry.npmjs.org/pify/-/pify-2.3.0.tgz 56ms
npm http fetch GET 200 https://registry.npmjs.org/mkdirp/-/mkdirp-0.5.1.tgz 58ms
npm http fetch GET 200
https://registry.npmjs.org/spawn-rx/-/spawn-rx-2.0.12.tgz 40ms
npm http fetch GET 200 https://registry.npmjs.org/keyboard-layout 769ms
npm http fetch GET 200 https://registry.npmjs.org/electron-remote 771ms
npm http fetch GET 200 https://registry.npmjs.org/rxjs-serial-subscription 745ms
npm http fetch GET 200 https://registry.npmjs.org/@paulcbetts%2fcld 1496ms
npm http fetch GET 200 https://registry.npmjs.org/@paulcbetts%2fspellchecker
1627ms
npm http fetch GET 200 https://registry.npmjs.org/rimraf 39ms
npm http fetch GET 200 https://registry.npmjs.org/underscore 39ms
npm http fetch GET 200 https://registry.npmjs.org/nan 42ms
npm http fetch GET 200 https://registry.npmjs.org/glob 45ms
npm http fetch GET 200 https://registry.npmjs.org/glob/-/glob-5.0.15.tgz 36ms
npm http fetch GET 200 https://registry.npmjs.org/inherits 42ms
npm http fetch GET 200
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Here's a gdb backtrace from /usr/bin/node when ran with "run /usr/bin/npm --verbose install electron-spellchecker@1.1.2": Thread 1 "npm" received signal SIGSEGV, Segmentation fault. 0xb70128ab in node::fs::FSReqWrap::~FSReqWrap() () from /usr/lib/i386-linux-gnu/libnode.so.64 (gdb) bt #0 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::allocator >, std::allocatorstd::char_traits, std::allocator > > > const&, std::vector, std::allocator >, std::allocatorstd::char_traits, std::allocator > > > 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
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
On Tue, Feb 12, 2019 at 12:01 AM, Jérémy Lal wrote: Do you get some log in ~/.npm ? Since nodejs has a test suite, and since it crashes when extracting tgz, obvious culprit is node-tar, but i can't shoot something blindly if i don't have a (javascript) stack trace. No, I don't see any logs under ~/.npm. If you have an idea on how to get one, let me know. Best, Teemu
Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386
Le lun. 11 févr. 2019 à 20:39, Teemu Ikonen a écrit : > Package: npm > Version: 5.8.0+ds6-3 > Severity: normal > > I get a repeatable segfault from npm install by doing the following on > i386 (deleting the local .npm and node_modules dirs is not needed to > reproduce). > > -*- > > $ rm -rf .npm/ > $ rm -rf node_modules/ > $ npm --verbose install electron-spellchecker@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-spellchecker@1.1.2' ] > npm info using npm@5.8.0 > npm info using node@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-expansion@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. 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
Bug#922075: npm: segfault during extract on i386
Package: npm Version: 5.8.0+ds6-3 Severity: normal I get a repeatable segfault from npm install by doing the following on i386 (deleting the local .npm and node_modules dirs is not needed to reproduce). -*- $ rm -rf .npm/ $ rm -rf node_modules/ $ npm --verbose install electron-spellchecker@1.1.2 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-spellchecker@1.1.2' ] npm info using npm@5.8.0 npm info using node@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-expansion@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
