build 12.13.0 on mips64el segfault around mksnapshot #30304

Activity

1. kapouer

   changed the title [-]build 12.13.0 on mips64el segfault at node_mksnapshot.cc[/-] [+]build 12.13.0 on mips64el segfault around mksnapshot[/+] on Nov 6, 2019
2. bnoordhuis

   added

   buildIssues and PRs related to Node.js builds or CI infrastructure.Issues and PRs related to Node.js builds or CI infrastructure.

   mipsIssues and PRs related to the MIPS architecture.Issues and PRs related to the MIPS architecture.

   on Nov 6, 2019
3. bnoordhuis commented on Nov 6, 2019

   

   bnoordhuis

   on Nov 6, 2019

   Member

   More actions

   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.
4. bnoordhuis commented on Nov 12, 2019

   

   bnoordhuis

   on Nov 12, 2019

   Member

   More actions

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

   closed this as completedon Nov 12, 2019
6. KungFuJesus commented on Jul 10, 2020

   

   KungFuJesus

   on Jul 10, 2020

   Last edited by KungFuJesus

   More actions

   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.
7. kapouer commented on Jul 10, 2020

   

   kapouer

   on Jul 10, 2020

   ContributorAuthor

   More actions

   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
8. KungFuJesus commented on Jul 10, 2020

   

   KungFuJesus

   on Jul 10, 2020

   More actions

   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.