quartz: Crash while using Build --serve and modifying vault content live

Describe the bug Not really a clue… Seems to hang when attempting to emit files after they have been updated in some way.

To Reproduce Reliable replication not possible or unknown

  1. Start quartz using build command with --serve argument
  2. Wait until webserver is spun up
  3. Modify the page that the webserver most recently served
  4. After the Detected change, rebuilding message, modify it again (These steps are best achieved one immediately after the other, typing a long sentence can work)
  5. It will parse successfully, then start emitting
  6. it will then hang at this point until an error occurs

Expected behavior Either A. Emitting to complete and reprocessing to start occurring immediately B. Emitting to self cancel and pause for a set period before reprocessing

Screenshots and Source Entire log from start of command to error and crash:

Quartz v4.2.1

Cleaned output directory `public` in 3ms
Found 3 input files from `content` in 10ms
Parsed 3 Markdown files in 114ms
Filtered out 0 files in 46μs
Emitted 14 files to `public` in 62ms
Done processing 3 files in 191ms
Started a Quartz server listening at http://localhost:8080
hint: exit with ctrl+c
[200] /
[200] /index.css
[200] /prescript.js
[200] /postscript.js
[200] /static/contentIndex.json
[200] /Quests/Quest-Log
[404] /Adventurers
[200] /Build-Rules
Detected change, rebuilding...
Parsed 1 Markdown files in 44ms
Filtered out 0 files in 15μs
⠹ Emitting output files
<--- Last few GCs --->

[22440:0000021E689DDB20]   166362 ms: Mark-Compact 4046.6 (4135.3) -> 4035.6 (4139.8) MB, 939.96 / 0.00 ms  (average mu = 0.590, current mu = 0.019) allocation failure; scavenge might not succeed
[22440:0000021E689DDB20]   168154 ms: Mark-Compact 4051.5 (4139.8) -> 4040.0 (4144.3) MB, 1773.06 / 0.00 ms  (average mu = 0.314, current mu = 0.011) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 00007FF6B2F56E7B node::SetCppgcReference+16075
 2: 00007FF6B2ECD996 v8::base::CPU::num_virtual_address_bits+79190
 3: 00007FF6B2ECFBA5 v8::base::CPU::num_virtual_address_bits+87909
 4: 00007FF6B393D9E1 v8::Isolate::ReportExternalAllocationLimitReached+65
 5: 00007FF6B3927178 v8::Function::Experimental_IsNopFunction+1336
 6: 00007FF6B3788AA0 v8::Platform::SystemClockTimeMillis+659328
 7: 00007FF6B3785B28 v8::Platform::SystemClockTimeMillis+647176
 8: 00007FF6B379AE3A v8::Platform::SystemClockTimeMillis+733978
 9: 00007FF6B379B6B7 v8::Platform::SystemClockTimeMillis+736151
10: 00007FF6B37A42EE v8::Platform::SystemClockTimeMillis+772046
11: 00007FF6B37B4C36 v8::Platform::SystemClockTimeMillis+839958
12: 00007FF6B37B9808 v8::Platform::SystemClockTimeMillis+859368
13: 00007FF6B3530F9A v8::base::Thread::StartSynchronously+372186
14: 00007FF6B344E735 v8::CodeEvent::GetFunctionName+2549
15: 00007FF65399AAFA
fatal error: all goroutines are asleep - deadlock!

Desktop (please complete the following information):

  • Quartz Version: 4.1.2
  • node Version: v20.11.0
  • npm version: 10.2.4
  • OS: Windows 10 Pro build 19045.3930
  • Browser: Chrome

Additional context Content and vault are symlinked through command mklink Additional files and/or vault available on request.

About this issue

  • Original URL
  • State: open
  • Created 5 months ago
  • Reactions: 3
  • Comments: 24 (9 by maintainers)

Most upvoted comments

@aarnphm can you take a look at this actually LOL i cannot reproduce this at all

No lol, I already know the exact line it dies on quartz/plugins/emitters/componentResources.ts L64-L66 but this seems like esbuild. Nothing else there is computationally/memory expensive, it’s just string concatenation that is <1MB

Non-symlink still crashes:

<--- Last few GCs --->

[6624:000001E60755C4B0]   329520 ms: Mark-Compact 4051.7 (4138.9) -> 4040.5 (4143.7) MB, 860.18 / 0.00 ms  (average mu = 0.372, current mu = 0.024) allocation failure; scavenge might not succeed
[6624:000001E60755C4B0]   331212 ms: Mark-Compact 4056.3 (4143.7) -> 4045.3 (4148.4) MB, 1673.58 / 0.00 ms  (average mu = 0.167, current mu = 0.011) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 00007FF7AE8A6E7B node::SetCppgcReference+16075
 2: 00007FF7AE81D996 v8::base::CPU::num_virtual_address_bits+79190
 3: 00007FF7AE81FBA5 v8::base::CPU::num_virtual_address_bits+87909
 4: 00007FF7AF28D9E1 v8::Isolate::ReportExternalAllocationLimitReached+65
 5: 00007FF7AF277178 v8::Function::Experimental_IsNopFunction+1336
 6: 00007FF7AF0D8AA0 v8::Platform::SystemClockTimeMillis+659328
 7: 00007FF7AF0D5B28 v8::Platform::SystemClockTimeMillis+647176
 8: 00007FF7AF0EAE3A v8::Platform::SystemClockTimeMillis+733978
 9: 00007FF7AF0EB6B7 v8::Platform::SystemClockTimeMillis+736151
10: 00007FF7AF0F9FAF v8::Platform::SystemClockTimeMillis+795791
11: 00007FF7AEDBA565 v8::CodeEvent::GetFunctionName+116773
12: 00007FF7AF33EFAE v8::PropertyDescriptor::writable+677134
13: 00007FF7AF33F703 v8::PropertyDescriptor::writable+679011
14: 00007FF72F7BC6B7

Is there a flag I can set so that it gives more helpful information or is this all you need?

Super weird, keep me posted. I haven’t been able to reproduce this yet but let me know if you have something consistent