investigate flaky test-domain-error-types in CI #30498

Trott · 2019-11-15T19:29:22Z

test/parallel/test-domain-error-types.js is flaky on containered shared-lib debug builds in CI.

Example failures:

https://ci.nodejs.org/job/node-test-commit-linux-containered/nodes=ubuntu1804_sharedlibs_debug_x64/15829/consoleText

not ok 486 parallel/test-domain-error-types
  ---
  duration_ms: 3.479
  severity: crashed
  exitcode: -11
  stack: |-
  ...

https://ci.nodejs.org/job/node-test-commit-linux-containered/nodes=ubuntu1804_sharedlibs_debug_x64/15824/consoleText

not ok 485 parallel/test-domain-error-types
  ---
  duration_ms: 3.577
  severity: crashed
  exitcode: -11
  stack: |-
  ...

https://ci.nodejs.org/job/node-test-commit-linux-containered/nodes=ubuntu1804_sharedlibs_debug_x64/15820/consoleText

not ok 484 parallel/test-domain-error-types
  ---
  duration_ms: 3.53
  severity: crashed
  exitcode: -11
  stack: |-
  ...

Not sure who is in a position to dig in to figure this out so I might be pinging a bit more widely than some people may prefer, so apologies in advance if so. Pings: @nodejs/build @nodejs/testing @nodejs/domains @nodejs/docker @nodejs/diagnostics

The text was updated successfully, but these errors were encountered:

Trott · 2019-11-16T16:15:10Z

This is happening a lot. I'm not sure it's necessary to paste more of these in here at this point, but here's one more.

https://ci.nodejs.org/job/node-test-commit-linux-containered/15862/nodes=ubuntu1804_sharedlibs_debug_x64/consoleText

not ok 592 parallel/test-domain-error-types
  ---
  duration_ms: 2.530
  severity: crashed
  exitcode: -11
  stack: |-
  ...

Trott · 2019-11-16T16:16:27Z

@addaleax

gireeshpunathil · 2019-11-18T12:20:58Z

today seen again:

09:00:01 not ok 548 parallel/test-domain-error-types
09:00:01   ---
09:00:01   duration_ms: 1.718
09:00:01   severity: crashed
09:00:01   exitcode: -11
09:00:01   stack: |-

ref: https://ci.nodejs.org/job/node-test-commit-linux-containered/nodes=ubuntu1804_sharedlibs_debug_x64/15910/consoleFull

addaleax · 2019-11-18T14:56:28Z

Backtrace with optimized V8 debug:

#0  v8::internal::Bitmap::MarkBitFromIndex (index=<optimized out>, this=<optimized out>) at ../deps/v8/src/heap/marking.h:135
#1  v8::internal::MarkingStateBase<v8::internal::ConcurrentMarkingState, (v8::internal::AccessMode)0>::MarkBitFrom (this=0x7f4d5ea6be20, addr=<optimized out>, p=<optimized out>) at ../deps/v8/src/heap/mark-compact.h:42
#2  v8::internal::MarkingStateBase<v8::internal::ConcurrentMarkingState, (v8::internal::AccessMode)0>::MarkBitFrom (this=0x7f4d5ea6be20, obj=...) at ../deps/v8/src/heap/mark-compact.h:36
#3  v8::internal::MarkingStateBase<v8::internal::ConcurrentMarkingState, (v8::internal::AccessMode)0>::WhiteToGrey (this=0x7f4d5ea6be20, obj=...) at ../deps/v8/src/heap/mark-compact-inl.h:35
#4  v8::internal::ConcurrentMarkingVisitor::MarkObject (object=..., this=0x7f4d5ea6bdf0) at ../deps/v8/src/heap/concurrent-marking.cc:540
#5  v8::internal::ConcurrentMarkingVisitor::ProcessStrongHeapObject<v8::internal::FullHeapObjectSlot> (heap_object=..., slot=..., host=..., this=0x7f4d5ea6bdf0) at ../deps/v8/src/heap/concurrent-marking.cc:115
#6  v8::internal::ConcurrentMarkingVisitor::VisitPointersImpl<v8::internal::FullObjectSlot> (this=this@entry=0x7f4d5ea6bdf0, host=..., host@entry=..., start=start@entry=..., end=...) at ../deps/v8/src/heap/concurrent-marking.cc:158
#7  0x00000000013a8558 in v8::internal::ConcurrentMarkingVisitor::VisitPointers (end=..., start=..., host=..., this=0x7f4d5ea6bdf0) at ../deps/v8/src/heap/concurrent-marking.cc:140
#8  v8::internal::BodyDescriptorBase::IteratePointers<v8::internal::ConcurrentMarkingVisitor> (obj=..., obj@entry=..., start_offset=start_offset@entry=8, end_offset=end_offset@entry=48, v=v@entry=0x7f4d5ea6bdf0) at ../deps/v8/src/objects/objects-body-descriptors-inl.h:127
#9  0x00000000013ac927 in v8::internal::FixedBodyDescriptor<8, 48, 48>::IterateBody<v8::internal::ConcurrentMarkingVisitor> (v=0x7f4d5ea6bdf0, obj=..., map=...) at ../deps/v8/src/objects/objects-body-descriptors.h:93
#10 v8::internal::FixedBodyDescriptor<8, 48, 48>::IterateBody<v8::internal::ConcurrentMarkingVisitor> (object_size=<optimized out>, v=0x7f4d5ea6bdf0, obj=..., map=...) at ../deps/v8/src/objects/objects-body-descriptors.h:99
#11 v8::internal::SubclassBodyDescriptor<v8::internal::FixedBodyDescriptor<8, 48, 48>, v8::internal::FixedBodyDescriptor<56, 72, 72> >::IterateBody<v8::internal::ConcurrentMarkingVisitor> (object_size=<optimized out>, v=0x7f4d5ea6bdf0, obj=..., map=...) at ../deps/v8/src/objects/objects-body-descriptors.h:173
#12 v8::internal::HeapVisitor<int, v8::internal::ConcurrentMarkingVisitor>::VisitSyntheticModule (object=..., map=..., this=0x7f4d5ea6bdf0) at ../deps/v8/src/heap/objects-visiting-inl.h:98
#13 v8::internal::HeapVisitor<int, v8::internal::ConcurrentMarkingVisitor>::Visit (this=this@entry=0x7f4d5ea6bdf0, map=..., object=object@entry=...) at ../deps/v8/src/heap/objects-visiting-inl.h:45
#14 0x00000000013addbc in v8::internal::ConcurrentMarking::Run (this=0x561b5b0, task_id=<optimized out>, task_state=<optimized out>) at ../deps/v8/src/heap/concurrent-marking.cc:815
#15 0x00000000012c005e in v8::internal::CancelableTask::Run (this=<optimized out>) at ../deps/v8/src/tasks/cancelable-task.h:155
#16 0x0000000000fa468d in node::(anonymous namespace)::PlatformWorkerThread (data=0x55a72e0) at ../src/node_platform.cc:45
#17 0x00007f4d5f6406ba in start_thread (arg=0x7f4d5ea6d700) at pthread_create.c:333
#18 0x00007f4d5f37641d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

I’ll try to get one from a non-optimized build but this is most likely a V8 GC bug.

@nodejs/v8

addaleax · 2019-11-18T16:19:57Z

Full stack trace:

#0  0x000000000203cb2f in v8::base::Relaxed_Load (ptr=0xdeadbeedbeac0008) at ../deps/v8/src/base/atomicops_internals_portable.h:183
#1  0x0000000002396aa6 in v8::base::AsAtomicImpl<long>::Relaxed_Load<unsigned long const> (addr=0xdeadbeedbeac0008) at ../deps/v8/src/base/atomic-utils.h:77
#2  0x0000000002396a84 in v8::internal::BasicMemoryChunk::GetFlags<(v8::internal::AccessMode)0> (this=0xdeadbeedbeac0000) at ../deps/v8/src/heap/basic-memory-chunk.h:152
#3  0x0000000002392b3d in v8::internal::BasicMemoryChunk::IsFlagSet<(v8::internal::AccessMode)0> (this=0xdeadbeedbeac0000, flag=v8::internal::BasicMemoryChunk::NEVER_EVACUATE) at ../deps/v8/src/heap/basic-memory-chunk.h:135
#4  0x0000000002393ca5 in v8::internal::MemoryChunk::IsEvacuationCandidate<(v8::internal::AccessMode)0> (this=0xdeadbeedbeac0000) at ../deps/v8/src/heap/spaces.h:806
#5  0x000000000238f280 in v8::internal::MarkCompactCollector::RecordSlot (object=..., slot=..., target=...) at ../deps/v8/src/heap/mark-compact-inl.h:486
#6  0x000000000248be84 in v8::internal::MarkingVisitor<(v8::internal::FixedArrayVisitationMode)0, (v8::internal::TraceRetainingPathMode)0, v8::internal::IncrementalMarkingState>::VisitPointerImpl<v8::internal::FullObjectSlot> (this=0x7ffe2d8e7630, host=..., slot=...) at ../deps/v8/src/heap/mark-compact-inl.h:298
#7  0x0000000002485edf in v8::internal::MarkingVisitor<(v8::internal::FixedArrayVisitationMode)0, (v8::internal::TraceRetainingPathMode)0, v8::internal::IncrementalMarkingState>::VisitPointer (this=0x7ffe2d8e7630, host=..., p=...) at ../deps/v8/src/heap/mark-compact.h:955
#8  0x000000000248bdaf in v8::internal::MarkingVisitor<(v8::internal::FixedArrayVisitationMode)0, (v8::internal::TraceRetainingPathMode)0, v8::internal::IncrementalMarkingState>::VisitPointersImpl<v8::internal::FullObjectSlot> (this=0x7ffe2d8e7630, host=..., start=..., end=...) at ../deps/v8/src/heap/mark-compact-inl.h:323
#9  0x0000000002485d58 in v8::internal::MarkingVisitor<(v8::internal::FixedArrayVisitationMode)0, (v8::internal::TraceRetainingPathMode)0, v8::internal::IncrementalMarkingState>::VisitPointers (this=0x7ffe2d8e7630, host=..., start=..., end=...) at ../deps/v8/src/heap/mark-compact.h:962
#10 0x000000000248bb58 in v8::internal::BodyDescriptorBase::IteratePointers<v8::internal::MarkingVisitor<(v8::internal::FixedArrayVisitationMode)0, (v8::internal::TraceRetainingPathMode)0, v8::internal::IncrementalMarkingState> > (obj=..., start_offset=8, end_offset=48, v=0x7ffe2d8e7630) at ../deps/v8/src/objects/objects-body-descriptors-inl.h:127
#11 0x000000000248eb6f in v8::internal::FixedBodyDescriptor<8, 48, 48>::IterateBody<v8::internal::MarkingVisitor<(v8::internal::FixedArrayVisitationMode)0, (v8::internal::TraceRetainingPathMode)0, v8::internal::IncrementalMarkingState> > (map=..., obj=..., v=0x7ffe2d8e7630) at ../deps/v8/src/objects/objects-body-descriptors.h:93
#12 0x000000000248c316 in v8::internal::FixedBodyDescriptor<8, 48, 48>::IterateBody<v8::internal::MarkingVisitor<(v8::internal::FixedArrayVisitationMode)0, (v8::internal::TraceRetainingPathMode)0, v8::internal::IncrementalMarkingState> > (map=..., obj=..., object_size=72, v=0x7ffe2d8e7630) at ../deps/v8/src/objects/objects-body-descriptors.h:99
#13 0x00000000024869b9 in v8::internal::SubclassBodyDescriptor<v8::internal::FixedBodyDescriptor<8, 48, 48>, v8::internal::FixedBodyDescriptor<56, 72, 72> >::IterateBody<v8::internal::MarkingVisitor<(v8::internal::FixedArrayVisitationMode)0, (v8::internal::TraceRetainingPathMode)0, v8::internal::IncrementalMarkingState> > (map=..., obj=..., object_size=72, v=0x7ffe2d8e7630) at ../deps/v8/src/objects/objects-body-descriptors.h:173
#14 0x000000000247c8b2 in v8::internal::HeapVisitor<int, v8::internal::MarkingVisitor<(v8::internal::FixedArrayVisitationMode)0, (v8::internal::TraceRetainingPathMode)0, v8::internal::IncrementalMarkingState> >::VisitSyntheticModule (this=0x7ffe2d8e7630, map=..., object=...) at ../deps/v8/src/heap/objects-visiting-inl.h:98
#15 0x0000000002472400 in v8::internal::HeapVisitor<int, v8::internal::MarkingVisitor<(v8::internal::FixedArrayVisitationMode)0, (v8::internal::TraceRetainingPathMode)0, v8::internal::IncrementalMarkingState> >::Visit (this=0x7ffe2d8e7630, map=..., object=...) at ../deps/v8/src/heap/objects-visiting-inl.h:45
#16 0x0000000002467e42 in v8::internal::MarkCompactCollector::ProcessMarkingWorklistInternal<(v8::internal::MarkCompactCollector::MarkingWorklistProcessingMode)0> (this=0x700f770) at ../deps/v8/src/heap/mark-compact.cc:1754
#17 0x0000000002451e64 in v8::internal::MarkCompactCollector::ProcessMarkingWorklist (this=0x700f770) at ../deps/v8/src/heap/mark-compact.cc:1721
#18 0x0000000002452c75 in v8::internal::MarkCompactCollector::MarkLiveObjects (this=0x700f770) at ../deps/v8/src/heap/mark-compact.cc:1863
#19 0x000000000244cb43 in v8::internal::MarkCompactCollector::CollectGarbage (this=0x700f770) at ../deps/v8/src/heap/mark-compact.cc:514
#20 0x00000000023f7d25 in v8::internal::Heap::MarkCompact (this=0x6fd29a8) at ../deps/v8/src/heap/heap.cc:2179
#21 0x00000000023f6a3c in v8::internal::Heap::PerformGarbageCollection (this=0x6fd29a8, collector=v8::internal::MARK_COMPACTOR, gc_callback_flags=v8::kNoGCCallbackFlags) at ../deps/v8/src/heap/heap.cc:1955
#22 0x00000000023f4955 in v8::internal::Heap::CollectGarbage (this=0x6fd29a8, space=v8::internal::NEW_SPACE, gc_reason=v8::internal::GarbageCollectionReason::kAllocationFailure, gc_callback_flags=v8::kNoGCCallbackFlags) at ../deps/v8/src/heap/heap.cc:1545
#23 0x00000000024037c3 in v8::internal::Heap::AllocateRawWithLightRetrySlowPath (this=0x6fd29a8, size=16, allocation=v8::internal::AllocationType::kYoung, origin=v8::internal::AllocationOrigin::kRuntime, alignment=v8::internal::kWordAligned) at ../deps/v8/src/heap/heap.cc:4918
#24 0x00000000024038dc in v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath (this=0x6fd29a8, size=16, allocation=v8::internal::AllocationType::kYoung, origin=v8::internal::AllocationOrigin::kRuntime, alignment=v8::internal::kWordAligned) at ../deps/v8/src/heap/heap.cc:4933
#25 0x00000000023ce913 in v8::internal::Heap::AllocateRawWith<(v8::internal::Heap::AllocationRetryMode)1> (this=0x6fd29a8, size=16, allocation=v8::internal::AllocationType::kYoung, origin=v8::internal::AllocationOrigin::kRuntime, alignment=v8::internal::kWordAligned) at ../deps/v8/src/heap/heap-inl.h:269
#26 0x00000000023b21a7 in v8::internal::Factory::AllocateRawWithImmortalMap (this=0x6fc9640, size=16, allocation=v8::internal::AllocationType::kYoung, map=..., alignment=v8::internal::kWordAligned) at ../deps/v8/src/heap/factory.cc:214
#27 0x00000000023bbcc4 in v8::internal::Factory::NewForeign (this=0x6fc9640, addr=31307306) at ../deps/v8/src/heap/factory.cc:1737
#28 0x00000000023c48d0 in v8::internal::Factory::NewSyntheticModule (this=0x6fc9640, module_name=..., export_names=..., evaluation_steps=0x1ddb62a <node::loader::ModuleWrap::SyntheticModuleEvaluationStepsCallback(v8::Local<v8::Context>, v8::Local<v8::Module>)>) at ../deps/v8/src/heap/factory.cc:3079
#29 0x000000000207423b in v8::Module::CreateSyntheticModule (isolate=0x6fc9640, module_name=..., export_names=std::vector of length 15, capacity 15 = {...}, evaluation_steps=0x1ddb62a <node::loader::ModuleWrap::SyntheticModuleEvaluationStepsCallback(v8::Local<v8::Context>, v8::Local<v8::Module>)>) at ../deps/v8/src/api/api.cc:2363
#30 0x0000000001dd2a05 in node::loader::ModuleWrap::New (args=...) at ../src/module_wrap.cc:168
#31 0x000000000215e715 in v8::internal::FunctionCallbackArguments::Call (this=0x7ffe2d8e81c0, handler=...) at ../deps/v8/src/api/api-arguments-inl.h:158
#32 0x0000000002160d18 in v8::internal::(anonymous namespace)::HandleApiCallHelper<true> (isolate=0x6fc9640, function=..., new_target=..., fun_data=..., receiver=..., args=...) at ../deps/v8/src/builtins/builtins-api.cc:111
#33 0x000000000215efb4 in v8::internal::Builtin_Impl_HandleApiCall (args=..., isolate=0x6fc9640) at ../deps/v8/src/builtins/builtins-api.cc:137
#34 0x000000000215ee2f in v8::internal::Builtin_HandleApiCall (args_length=9, args_object=0x7ffe2d8e83d8, isolate=0x6fc9640) at ../deps/v8/src/builtins/builtins-api.cc:147
#35 0x00000000030d8c60 in Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit () at ../deps/v8/src/builtins/builtins-async-iterator-gen.cc:268
#36 0x0000000002e5bc01 in Builtins_JSBuiltinsConstructStub () at ../../deps/v8/../../deps/v8/src/builtins/base.tq:412

addaleax · 2019-11-19T18:38:14Z

I’m not really sure how to debug this correctly … valgrind is impractical here, I can’t run the test file in debug mode under it in less than three hours and even then I’d assume the test would still be flaky.

If the @nodejs/v8 team has any guidance/ideas for next steps, I’m all ears :)

targos · 2019-11-23T13:36:08Z

ptr=0xdeadbeedbeac0008

This looks a lot like kZapValue:

node/deps/v8/src/common/globals.h

Line 529 in eb30b2c

constexpr uint64_t kZapValue = uint64_t{0xdeadbeedbeadbeef};

Trott · 2019-11-24T16:52:28Z

Do we think we're likely to have something we can do here soon-ish or should we mark the test as flaky (or, probably better, skip on the one platform where there's a problem, if possible)?

Trott · 2019-11-24T17:44:38Z

Skip it for now on the one CI configuration where it fails frequently? #30629

Until nodejs#30498 is resolved, skip test-domain-error-types on debug builds. PR-URL: nodejs#30629 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>

addaleax · 2019-11-27T00:03:18Z

For future reference, this is the same bug as #30648. I’ll leave this open as a reminder to undo #30629 once this is resolved.

Original commit message: [heap] Ensure SyntheticModule is initialized before next allocation Ensure that all fields of `SyntheticModule` are set before creating the exports hash table for it, because the latter may trigger garbage collection, leading to crashes. This has been causing failures in the Node.js CI over the last weeks, after making the creating of synthetic modules part of Node’s startup sequence. (I am generally not very familiar with this part of the V8 code and there might be a better way, or possibly a way to add a reliable regression test, that I am not aware of.) Refs: nodejs#30498 Refs: nodejs#30648 Change-Id: I32da4b7bd888c6ec1421f34f5bd52e7bad154c1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1939752 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#65247} Refs: v8/v8@ca5b0ec Fixes: nodejs#30498 Fixes: nodejs#30648

Ensure that all fields of `SyntheticModule` are set before creating the exports hash table for it, because the latter may trigger garbage collection, leading to crashes. This has been causing failures in the Node.js CI over the last weeks, after making the creating of synthetic modules part of Node’s startup sequence. (I am generally not very familiar with this part of the V8 code and there might be a better way, or possibly a way to add a reliable regression test, that I am not aware of.) Refs: nodejs/node#30498 Refs: nodejs/node#30648 Change-Id: I32da4b7bd888c6ec1421f34f5bd52e7bad154c1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1939752 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#65247}

Until #30498 is resolved, skip test-domain-error-types on debug builds. PR-URL: #30629 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>

Original commit message: [heap] Ensure SyntheticModule is initialized before next allocation Ensure that all fields of `SyntheticModule` are set before creating the exports hash table for it, because the latter may trigger garbage collection, leading to crashes. This has been causing failures in the Node.js CI over the last weeks, after making the creating of synthetic modules part of Node’s startup sequence. (I am generally not very familiar with this part of the V8 code and there might be a better way, or possibly a way to add a reliable regression test, that I am not aware of.) Refs: #30498 Refs: #30648 Change-Id: I32da4b7bd888c6ec1421f34f5bd52e7bad154c1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1939752 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#65247} Refs: https://github.com/v8/v8/commit/ \ ca5b0ec2722d2af4551c01ca78921fa16a26ae72 Fixes: #30498 Fixes: #30648 PR-URL: #30708 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Jiawen Geng <technicalcute@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>

Until #30498 is resolved, skip test-domain-error-types on debug builds. PR-URL: #30629 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>

Original commit message: [heap] Ensure SyntheticModule is initialized before next allocation Ensure that all fields of `SyntheticModule` are set before creating the exports hash table for it, because the latter may trigger garbage collection, leading to crashes. This has been causing failures in the Node.js CI over the last weeks, after making the creating of synthetic modules part of Node’s startup sequence. (I am generally not very familiar with this part of the V8 code and there might be a better way, or possibly a way to add a reliable regression test, that I am not aware of.) Refs: #30498 Refs: #30648 Change-Id: I32da4b7bd888c6ec1421f34f5bd52e7bad154c1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1939752 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#65247} Refs: https://github.com/v8/v8/commit/ \ ca5b0ec2722d2af4551c01ca78921fa16a26ae72 Fixes: #30498 Fixes: #30648 PR-URL: #30708 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Jiawen Geng <technicalcute@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>

Trott added the flaky-test Issues and PRs related to the tests with unstable failures on the CI. label Nov 15, 2019

This was referenced Nov 24, 2019

net: replaced vars to lets and consts #30401

Closed

test: Use object spread instead of object.assign #30412

Closed

Trott mentioned this issue Nov 24, 2019

test: skip test-domain-error-types in debug mode temporariliy #30629

Merged

2 tasks

addaleax mentioned this issue Nov 26, 2019

investigate flaky test_make_callback/test-async-hooks-gcable in CI #30648

Closed

addaleax self-assigned this Nov 27, 2019

addaleax added the v8 engine Issues and PRs related to the V8 dependency. label Nov 27, 2019

addaleax mentioned this issue Nov 28, 2019

deps: V8: cherry-pick ca5b0ec #30708

Closed

2 tasks

gireeshpunathil closed this as completed in 29b5432 Nov 29, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

investigate flaky test-domain-error-types in CI #30498

investigate flaky test-domain-error-types in CI #30498

Trott commented Nov 15, 2019

Trott commented Nov 16, 2019 •

edited

Loading

Trott commented Nov 16, 2019

gireeshpunathil commented Nov 18, 2019

addaleax commented Nov 18, 2019

addaleax commented Nov 18, 2019

addaleax commented Nov 19, 2019

targos commented Nov 23, 2019

Trott commented Nov 24, 2019

Trott commented Nov 24, 2019

addaleax commented Nov 27, 2019

investigate flaky test-domain-error-types in CI #30498

investigate flaky test-domain-error-types in CI #30498

Comments

Trott commented Nov 15, 2019

Trott commented Nov 16, 2019 • edited Loading

Trott commented Nov 16, 2019

gireeshpunathil commented Nov 18, 2019

addaleax commented Nov 18, 2019

addaleax commented Nov 18, 2019

addaleax commented Nov 19, 2019

targos commented Nov 23, 2019

Trott commented Nov 24, 2019

Trott commented Nov 24, 2019

addaleax commented Nov 27, 2019

Trott commented Nov 16, 2019 •

edited

Loading