镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Core dump while adding to Set #43551

Description

@hemanth

Version

v19.0.0-pre

Platform

Linux codespaces_2ecb6d 5.4.0-1074-azure #77~18.04.1-Ubuntu SMP Wed Mar 30 15:36:02 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

> all = new Set(require('module').builtinModules)
> all.forEach(k => all.add(`node:${k}`))

<--- Last few GCs --->

[7264:0x5592d00a66e0]   177263 ms: Mark-sweep 1959.9 (2091.2) -> 1958.8 (2091.2) MB, 56.9 / 0.0 ms  (average mu = 0.954, current mu = 0.739) allocation failure; scavenge might not succeed
[7264:0x5592d00a66e0]   177444 ms: Mark-sweep 1974.5 (2091.2) -> 1973.4 (2123.2) MB, 132.8 / 0.0 ms  (average mu = 0.839, current mu = 0.265) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0x5592ca8d4684 node::Abort() [node]
 2: 0x5592ca7c43ea node::FatalError(char const*, char const*) [node]
 3: 0x5592caaeff1a v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0x5592caaf01ff v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0x5592cacfd5e9  [node]
 6: 0x5592cad1124f v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 7: 0x5592cace7c17 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 8: 0x5592cace8f1b v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 9: 0x5592cacc50d6 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [node]
10: 0x5592cacbcd98 v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawWithImmortalMap(int, v8::internal::AllocationType, v8::internal::Map, v8::internal::AllocationAlignment) [node]
11: 0x5592cacbf22e v8::internal::FactoryBase<v8::internal::Factory>::NewRawOneByteString(int, v8::internal::AllocationType) [node]
12: 0x5592cb00e548 v8::internal::String::SlowFlatten(v8::internal::Isolate*, v8::internal::Handle<v8::internal::ConsString>, v8::internal::AllocationType) [node]
13: 0x5592cb0115f2 v8::internal::String::SlowEquals(v8::internal::Isolate*, v8::internal::Handle<v8::internal::String>, v8::internal::Handle<v8::internal::String>) [node]
14: 0x5592cb13730a v8::internal::Runtime_StringEqual(int, unsigned long*, v8::internal::Isolate*) [node]
15: 0x5592cb5bb0b9  [node]
Aborted (core dumped)

^ In REPL or Just script

How often does it reproduce? Is there a required condition?

Everytime

What is the expected behavior?

We should be able to add them all to the Set.

What do you see instead?

Core dump

Additional information

P.S: Same happen on v17+

Activity

  1. ljharb commented on Jun 23, 2022

    @ljharb
    SponsorMember

    I think this might be because forEach visits newly added items - iow, this should work:

    all = new Set(require('module').builtinModules)
    [...all].forEach(k => all.add(`node:${k}`))
  2. hemanth commented on Jun 23, 2022

    @hemanth
    ContributorAuthor

    Ah, so we live with it?

    image

  3. ljharb commented on Jun 23, 2022

    @ljharb
    SponsorMember

    Yep, it's the way forEach is supposed to work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions