search

vercel / next.js

The React Framework
https://nextjs.org
MIT License
127.09k stars 27.01k forks source link

Keeps Crashing NextJs 13, but works after restarting the server #43625

Closed budzHors7 closed 1 year ago

budzHors7 commented 1 year ago

Verify canary release

Provide environment information

After some time coding, 2 times in 2-3hrs, but after I restart the server ( using PNPM: pnpm dev ) & I'm not using the turbopack.

<--- Last few GCs --->

[5992:000001E2C9CB5E70] 4629546 ms: Mark-sweep 2043.0 (2061.0) -> 2037.8 (2061.2) MB, 181.9 / 0.0 ms (average mu = 0.253, current mu = 0.225) allocation failure; scavenge might not succeed [5992:000001E2C9CB5E70] 4629789 ms: Mark-sweep 2041.9 (2061.2) -> 2037.8 (2059.7) MB, 204.1 / 0.0 ms (average mu = 0.209, current mu = 0.160) allocation failure; scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory 1: 00007FF65810825F node_api_throw_syntax_error+176047 2: 00007FF65808EF56 v8::base::CPU::num_virtual_address_bits+67686 3: 00007FF658090313 v8::base::CPU::num_virtual_address_bits+72739 4: 00007FF658BA8341 v8::Isolate::ReportExternalAllocationLimitReached+65 5: 00007FF658B92FF6 v8::internal::V8::FatalProcessOutOfMemory+662 6: 00007FF6589FA200 v8::internal::EmbedderStackStateScope::ExplicitScopeForTesting+112 7: 00007FF658A070F2 v8::internal::Heap::PublishPendingAllocations+1106 8: 00007FF658A04242 v8::internal::Heap::PageFlagsAreConsistent+3122 9: 00007FF6589F72A9 v8::internal::Heap::CollectGarbage+2729 10: 00007FF658A0D006 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath+2150 11: 00007FF658A0D92F v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath+95 12: 00007FF658A1CAA0 v8::internal::Factory::NewFillerObject+448 13: 00007FF6586E74B5 v8::internal::Runtime::SetObjectProperty+21029 14: 00007FF658C4A891 v8::internal::SetupIsolateDelegate::SetupHeap+577585 15: 00007FF658C4B848 v8::internal::SetupIsolateDelegate::SetupHeap+581608 16: 00007FF658CB0879 v8::internal::SetupIsolateDelegate::SetupHeap+995353 17: 00007FF658C3AB10 v8::internal::SetupIsolateDelegate::SetupHeap+512688 18: 00007FF5D936232E  ELIFECYCLE  Command failed with exit code 134.

Which example does this report relate to?

NextJs13

What browser are you using? (if relevant)

Chrome 107.0.5304.122 (Official Build) (64-bit)

How are you deploying your application? (if relevant)

Not deployed yet

Describe the Bug

ELIFECYCLE  Command failed with exit code 134.

Expected Behavior

Stop showing this error.

To Reproduce

Please fix this, I'm just practising NextJs13

vnghia187 commented 1 year ago

related #43307

github-actions[bot] commented 1 year ago

We cannot recreate the issue with the provided information. Please add a reproduction in order for us to be able to investigate.

Why was this issue marked with the please add a complete reproduction label?

To be able to investigate, we need access to a reproduction to identify what triggered the issue. We prefer a link to a public GitHub repository (template), but you can also use a tool like CodeSandbox or StackBlitz.

To make sure the issue is resolved as quickly as possible, please make sure that the reproduction is as minimal as possible. This means that you should remove unnecessary code, files, and dependencies that do not contribute to the issue.

Please test your reproduction against the latest version of Next.js (next@canary) to make sure your issue has not already been fixed.

I added a link, why was it still marked?

Ensure the link is pointing to a codebase that is accessible (e.g. not a private repository). "example.com", "n/a", "will add later", etc. are not acceptable links -- we need to see a public codebase. See the above section for accepted links.

What happens if I don't provide a sufficient minimal reproduction?

Issues with the please add a complete reproduction label that receives no meaningful activity (e.g. new comments with a reproduction link) are automatically closed and locked after 30 days.

If your issue has not been resolved in that time and it has been closed/locked, please open a new issue with the required reproduction.

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps. Furthermore, you can upvote the issue using the :+1: reaction on the topmost comment (please do not comment "I have the same issue" without repro steps). Then, we can sort issues by votes to prioritize.

I think my reproduction is good enough, why aren't you looking into it quicker?

We look into every Next.js issue and constantly monitor open issues for new comments.

However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Upvoting issues to show your interest will help us prioritize and address them as quickly as possible. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.

Useful Resources

soylemezali42 commented 1 year ago

Hi @balazsorban44, I have the same problem for a week. I can't reproduce it till now. Do you accept the private repo intivatiton for further investigation.

As far as I see that the problem is related to module count in compilation. If you would say how to increase module count in a project. I think I will be able to reproduce the problem.

It runs smoothly in that number module:

Screenshot 2022-12-02 at 18 02 01

It will be crashing after some navigation.

Screenshot 2022-12-02 at 18 11 00
smoove commented 1 year ago

Same problem as the other people for me.

Working is nearly impossible, as even on a pretty beefy computer everything takes ages and crashes all the time.

Please look into this. Next 13 has so many fantastic concepts and I really wanna start upgrading my project, but rn it's sooo frustrating.

montanaflynn commented 1 year ago

Same thing happens to me, about once an hour. I just restart it once it crashes.

Here's the full log:

wait  - compiling...

<--- Last few GCs --->

[35187:0x128008000]  7577786 ms: Mark-sweep 4089.3 (4117.0) -> 4085.9 (4115.0) MB, 149.2 / 0.0 ms  (average mu = 0.115, current mu = 0.059) allocation failure scavenge might not succeed
[35187:0x128008000]  7577801 ms: Scavenge 4090.6 (4115.5) -> 4087.1 (4115.2) MB, 0.9 / 0.0 ms  (average mu = 0.115, current mu = 0.059) allocation failure 
[35187:0x128008000]  7577824 ms: Scavenge 4090.6 (4115.5) -> 4087.4 (4115.7) MB, 10.5 / 0.0 ms  (average mu = 0.115, current mu = 0.059) allocation failure 

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x100914704 node::Abort() [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
 2: 0x100914884 node::OnFatalError(char const*, char const*) [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
 3: 0x100a3a554 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
 4: 0x100a3a4e8 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
 5: 0x100b70c64 v8::internal::Heap::GarbageCollectionReasonToString(v8::internal::GarbageCollectionReason) [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
 6: 0x100b73528 v8::internal::Heap::MarkCompactPrologue() [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
 7: 0x100b71228 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
 8: 0x100b6f700 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
 9: 0x100b6ea98 v8::internal::Heap::HandleGCRequest() [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
10: 0x100b36da4 v8::internal::StackGuard::HandleInterrupts() [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
11: 0x100de01c4 v8::internal::Runtime_StackGuard(int, unsigned long*, v8::internal::Isolate*) [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
12: 0x101059bac Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
13: 0x10802a8fc 
14: 0x108394db4 
15: 0x10802a660 
16: 0x108394db4 
17: 0x10802a660 
18: 0x108394db4 
19: 0x1078ab380 
20: 0x10782e334 
21: 0x10782cc00 
22: 0x10782b778 
23: 0x1076eaf88 
24: 0x108526798 
25: 0x100feb62c Builtins_JSEntryTrampoline [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
26: 0x100feb2c4 Builtins_JSEntry [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
27: 0x100b18110 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
28: 0x100b177d8 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>*) [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
29: 0x100a4e6d4 v8::Function::Call(v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*) [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
30: 0x10086b6c0 node::InternalMakeCallback(node::Environment*, v8::Local<v8::Object>, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*, node::async_context) [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
31: 0x10088332c node::AsyncWrap::MakeCallback(v8::Local<v8::Function>, int, v8::Local<v8::Value>*) [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
32: 0x100918320 node::fs::FSReqCallback::Reject(v8::Local<v8::Value>) [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
33: 0x100918850 node::fs::FSReqAfterScope::Reject(uv_fs_s*) [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
34: 0x1009188b0 node::fs::FSReqAfterScope::Proceed() [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
35: 0x1009188e8 node::fs::AfterNoArgs(uv_fs_s*) [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
36: 0x102d6eff8 uv__work_done [/opt/homebrew/Cellar/libuv/1.44.2/lib/libuv.1.dylib]
37: 0x102d723d0 uv__async_io [/opt/homebrew/Cellar/libuv/1.44.2/lib/libuv.1.dylib]
38: 0x102d821e0 uv__io_poll [/opt/homebrew/Cellar/libuv/1.44.2/lib/libuv.1.dylib]
39: 0x102d727d0 uv_run [/opt/homebrew/Cellar/libuv/1.44.2/lib/libuv.1.dylib]
40: 0x10086be7c node::SpinEventLoop(node::Environment*) [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
41: 0x100947ac8 node::NodeMainInstance::Run(int*, node::Environment*) [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
42: 0x1009477b4 node::NodeMainInstance::Run() [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
43: 0x1008ec3c8 node::Start(int, char**) [/opt/homebrew/Cellar/node@16/16.17.0/bin/node]
44: 0x102f3908c 
/var/folders/9x/1j3smbtn4t53_q027jxp_8840000gn/T/dev-43d05654.sh: line 1: 35187 Abort trap: 6           next dev
andrew-mcmaster commented 1 year ago

This is happening to me as well and makes my dev server crash within about 2-3 minutes for a small website with only 4 pages plus a handful of simple blog posts. Builds are fine so far, just Dev.

mattcoker commented 1 year ago

Same here, about 5-6 times per day my dev server crashes due to memory issues.

Running on a 2019 MacBook Pro, with 16 GB of RAM.

soylemezali42 commented 1 year ago

It is related to #42514. Talks go on there.

balazsorban44 commented 1 year ago

This issue has been automatically closed because it received no activity for a month and had no reproduction to investigate. If you think it was closed by accident, please leave a comment. If you are running into a similar issue, please open a new issue with a reproduction. Thank you.

github-actions[bot] commented 1 year ago

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.