Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build 12.13.0 on mips64el segfault around mksnapshot #30304

Closed
kapouer opened this issue Nov 6, 2019 · 5 comments
Closed

build 12.13.0 on mips64el segfault around mksnapshot #30304

kapouer opened this issue Nov 6, 2019 · 5 comments
Labels
build Issues and PRs related to build files or the CI. mips Issues and PRs related to the MIPS architecture.

Comments

@kapouer
Copy link
Contributor

kapouer commented Nov 6, 2019

Version: 12.13.0
Platform: GNU/Linux
Subsystem: build

Now that 10.17.0 builds just fine, i gave a shot at 12.13.0 ;)

LD_LIBRARY_PATH=/<<PKGBUILDDIR>>/out/Release/lib.host:/<<PKGBUILDDIR>>/out/Release/lib.target:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd ../.; mkdir -p /<<PKGBUILDDIR>>/out/Release/obj/gen; "/<<PKGBUILDDIR>>/out/Release/node_mksnapshot" "/<<PKGBUILDDIR>>/out/Release/obj/gen/node_snapshot.cc"
Segmentation fault
make[2]: *** [node.target.mk:26: /<<PKGBUILDDIR>>/out/Release/obj/gen/node_snapshot.cc] Error 139

full log here

On mipsel, a different failure may indicate build is using too much memory at some point.
full log here

@kapouer kapouer changed the title build 12.13.0 on mips64el segfault at node_mksnapshot.cc build 12.13.0 on mips64el segfault around mksnapshot Nov 6, 2019
@bnoordhuis bnoordhuis added build Issues and PRs related to build files or the CI. mips Issues and PRs related to the MIPS architecture. labels Nov 6, 2019
@bnoordhuis
Copy link
Member

Segmentation fault

Is it possible to obtain a stack trace or core dump of the segfault?

Fatal process OOM in CodeRange setup: allocate virtual memory

mksnapshot tries to reserve (not commit) 2 GB of memory. That should normally succeed on a 64 bits system because there's plenty of address space. The reservation is so that runtime generated machine code can use near calls.

@bnoordhuis
Copy link
Member

@kapouer I'm closing this for lack of follow-up but feel free to reopen if you have more information.

@KungFuJesus
Copy link

KungFuJesus commented Jul 10, 2020

I just ran into this same problem building 14.5 on Big Endian PowerPC. I have a stack trace and core dump, but the lack of debug symbols admittedly might be less useful. The last function on the call stack is what didn't resolve, and it seems to in "Invoke".

#0  0x7c0802a6f8010010 in ?? ()                                                                                                                                                                   |
[Current thread is 1 (Thread 0x3fffbeb28010 (LWP 17840))]                                                                                                                                         |
(gdb) bt                                                                                                                                                                                          |
#0  0x7c0802a6f8010010 in ?? ()                                                                                                                                                                   |
#1  0x0000000010fad394 in .v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) ()                                       |
#2  0x0000000010fae388 in .v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle|
<v8::internal::Object>*) ()                                                                                                                                                                       |
#3  0x0000000010ee6ea4 in .v8::Function::Call(v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*) ()                                                                        |
#4  0x0000000010878be4 in .node::InitializePrimordials(v8::Local<v8::Context>) ()                                                                                                                 |
#5  0x0000000010877aa4 in .node::GetPerContextExports(v8::Local<v8::Context>) ()                                                                                                                  |
#6  0x0000000010878860 in .node::InitializePrimordials(v8::Local<v8::Context>) ()                                                                                                                 |
#7  0x0000000010878620 in .node::InitializeContextForSnapshot(v8::Local<v8::Context>) ()                                                                                                          |
#8  0x0000000010878cd4 in .node::InitializeContext(v8::Local<v8::Context>) ()                                                                                                                     |
#9  0x0000000010877c50 in .node::NewContext(v8::Isolate*, v8::Local<v8::ObjectTemplate>) ()                                                                                                       |
#10 0x0000000010871164 in .node::SnapshotBuilder::Generate(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<|
char, std::char_traits<char>, std::allocator<char> > > >, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<c|
har, std::char_traits<char>, std::allocator<char> > > >) ()                                                                                                                                       |
#11 0x000000001086fb08 in main ()  

Let me know if the ~50MB core might be useful to you.

@kapouer
Copy link
Contributor Author

kapouer commented Jul 10, 2020

Hi @KungFuJesus the problem you see is probably not related to this issue.
nodejs 14.4.0 builds on ppc64 on debian, however it did require this patch to be applied:
#33866

@KungFuJesus
Copy link

Applying the patch now and trying it out. It looks like you may be right but it takes a while to get there on a Quad G5. For the record I'm not expecting node to work after this, there are holes that require POWER5 for the JIT to work that I'm aware of, but this will at least get me further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Issues and PRs related to build files or the CI. mips Issues and PRs related to the MIPS architecture.
Projects
None yet
Development

No branches or pull requests

3 participants