I'll file a bug and try upgrading to a more recent release. Thanks! On Monday, 11 August 2025 at 09:00:11 UTC+2 omer...@chromium.org wrote:
> Looking at the current state of the code, I struggle to see how that could > happen. Did you try reproducing on ToT as well? > > Also, can you file a bug at https://issues.chromium.org/issues/new with > the component set to "Chromium > Blink > JavaScript > GarbageCollection"? > Please include the stack trace, your GN args, the repro, and any other > relevant information you think could be useful. > If you can have a standalone repro that doesn't require your git repo, > that would be preferable. > > On Sat, Aug 9, 2025 at 8:44 PM Kasper Isager Dalsgarð <kasper...@gmail.com> > wrote: > >> Using V8 v13.8.258.18 I'm consistently hitting the following DCHECK >> failure during heap garbage collection: >> >> ``` >> # >> # Fatal error in ../../../v8/src/heap/memory-reducer.cc, line 229 >> # Debug check failed: 0 < delay_ms (0 vs. 0). >> # >> ``` >> >> This is the stack trace at the time of the failure: >> >> ``` >> * thread #1, queue = 'com.apple.main-thread', stop reason = >> EXC_BREAKPOINT (code=1, subcode=0x1076866cc) >> * frame #0: 0x00000001076866cc libjs.dylib`v8::base::OS::Abort() >> [inlined] v8::base::OS::Abort()::$_0::operator()(this=<unavailable>) const >> at platform-posix.cc:729:7 [opt] >> frame #1: 0x00000001076866cc libjs.dylib`v8::base::OS::Abort() at >> platform-posix.cc:729:7 [opt] >> frame #2: 0x00000001076713c0 libjs.dylib`V8_Fatal(file=<unavailable>, >> line=<unavailable>, format=<unavailable>) at logging.cc:215:3 [opt] >> frame #3: 0x0000000107670cb8 libjs.dylib`v8::base::(anonymous >> namespace)::DefaultDcheckHandler(file=<unavailable>, line=<unavailable>, >> message=<unavailable>) at logging.cc:59:3 [opt] >> frame #4: 0x00000001063feff0 >> libjs.dylib`v8::internal::MemoryReducer::ScheduleTimer(this=0x00006070000014b0, >> >> delay_ms=0) at memory-reducer.cc:229:3 [opt] >> frame #5: 0x00000001063ff1a4 >> libjs.dylib`v8::internal::MemoryReducer::NotifyMarkCompact(this=0x00006070000014b0, >> >> committed_memory_before=<unavailable>) at memory-reducer.cc:123:5 [opt] >> frame #6: 0x0000000106337084 >> libjs.dylib`v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, >> >> v8::internal::GarbageCollectionReason, >> v8::GCCallbackFlags)::$_0::operator()(this=0x000000016fdfe318) const at >> heap.cc:1714:26 [opt] >> frame #7: 0x0000000106336ab0 libjs.dylib`void >> heap::base::Stack::SetMarkerAndCallbackImpl<v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, >> >> v8::internal::GarbageCollectionReason, >> v8::GCCallbackFlags)::$_0>(stack=0x000061d000001ba0, >> argument=<unavailable>, stack_end=<unavailable>) at stack.h:185:5 [opt] >> frame #8: 0x000000010781febc >> libjs.dylib`PushAllRegistersAndIterateStack + 40 >> frame #9: 0x0000000106311e88 >> libjs.dylib`v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, >> >> v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [inlined] void >> heap::base::Stack::SetMarkerIfNeededAndCallback<v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, >> >> v8::internal::GarbageCollectionReason, >> v8::GCCallbackFlags)::$_0>(this=<unavailable>, callback=(unnamed class) @ >> 0x000000016fdfe318) at stack.h:81:7 [opt] >> frame #10: 0x0000000106311e80 >> libjs.dylib`v8::internal::Heap::CollectGarbage(this=0x0000633000010938, >> space=<unavailable>, gc_reason=kFinalizeMarkingViaTask, >> gc_callback_flags=<unavailable>) at heap.cc:1655:11 [opt] >> frame #11: 0x000000010631f51c >> libjs.dylib`v8::internal::Heap::FinalizeIncrementalMarkingAtomically(v8::internal::GarbageCollectionReason) >> >> [inlined] v8::internal::Heap::CollectAllGarbage(this=0x0000633000010938, >> gc_flags=<unavailable>, gc_reason=kFinalizeMarkingViaTask, >> gc_callback_flags=<unavailable>) at heap.cc:1266:3 [opt] >> frame #12: 0x000000010631f50c >> libjs.dylib`v8::internal::Heap::FinalizeIncrementalMarkingAtomically(this=0x0000633000010938, >> >> gc_reason=kFinalizeMarkingViaTask) at heap.cc:3995:3 [opt] >> frame #13: 0x000000010633bf64 >> libjs.dylib`v8::internal::IncrementalMarkingJob::Task::RunInternal(this=0x0000606000016760) >> >> at incremental-marking-job.cc:135:34 [opt] >> ``` >> >> I have a test case at >> https://github.com/holepunchto/libjs/blob/main/test/threads-platform-loop.c >> that reproduces it reliably. It runs an isolate on the main thread that >> does a bunch of large allocations to trigger garbage collection and then a >> separate thread that runs background tasks posted to the embedder platform >> implementation. >> >> It doesn't seem to cause any observable behavior in production builds >> where the corresponding DCHECK is disabled, but I still can't help but >> worry that an invariant is being violated somewhere in the embedder >> platform implementation. >> >> -- >> -- >> v8-users mailing list >> v8-u...@googlegroups.com >> http://groups.google.com/group/v8-users >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to v8-users+u...@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/v8-users/81831323-681c-454b-816c-66a1f3772b99n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/v8-users/81831323-681c-454b-816c-66a1f3772b99n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/v8-users/4e819a94-3c75-4ba6-96fd-1ad2f7972a60n%40googlegroups.com.
