Change:
} function mountFiberRecursively( <del> fiber: Fiber, </del> <ins> firstChild: Fiber, </ins> parentFiber: Fiber | null, traverseSiblings: boolean, traceNearestHostComponentUpdate: boolean, ) { <del> if (__DEBUG__) { debug('mountFiberRecursively()', fiber, parentFiber); } </del> <ins> // Iterate over siblings rather than recursing. // This reduces the chance of stack overflow for wide trees (e.g. lists with many items). let fiber: Fiber | null = firstChild; while (fiber !== null) { if (__DEBUG__) { debug('mountFiberRecursively()', fiber, parentFiber); } </ins> <del> // If we have the tree selection from previous reload, try to match this Fiber. // Also remember whether to do the same for siblings. const mightSiblingsBeOnTrackedPath = updateTrackedPathStateBeforeMount( fiber, ); </del> <ins> // If we have the tree selection from previous reload, try to match this Fiber. // Also remember whether to do the same for siblings. const mightSiblingsBeOnTrackedPath = updateTrackedPathStateBeforeMount( fiber, ); </ins> <del> const shouldIncludeInTree = !shouldFilterFiber(fiber); if (shouldIncludeInTree) { recordMount(fiber, parentFiber); } </del> <ins> const shouldIncludeInTree = !shouldFilterFiber(fiber); if (shouldIncludeInTree) { recordMount(fiber, parentFiber); } </ins> <del> if (traceUpdatesEnabled) { if (traceNearestHostComponentUpdate) { const elementType = getElementTypeForFiber(fiber); // If an ancestor updated, we should mark the nearest host nodes for highlighting. if (elementType === ElementTypeHostComponent) { traceUpdatesForNodes.add(fiber.stateNode); traceNearestHostComponentUpdate = false; </del> <ins> if (traceUpdatesEnabled) { if (traceNearestHostComponentUpdate) { const elementType = getElementTypeForFiber(fiber); // If an ancestor updated, we should mark the nearest host nodes for highlighting. if (elementType === ElementTypeHostComponent) { traceUpdatesForNodes.add(fiber.stateNode); traceNearestHostComponentUpdate = false; } </ins> } <del> } // We intentionally do not re-enable the traceNearestHostComponentUpdate flag in this branch, // because we don't want to highlight every host node inside of a newly mounted subtree. } </del> <ins> // We intentionally do not re-enable the traceNearestHostComponentUpdate flag in this branch, // because we don't want to highlight every host node inside of a newly mounted subtree. } </ins> <del> const isSuspense = fiber.tag === ReactTypeOfWork.SuspenseComponent; if (isSuspense) { const isTimedOut = fiber.memoizedState !== null; if (isTimedOut) { // Special case: if Suspense mounts in a timed-out state, // get the fallback child from the inner fragment and mount // it as if it was our own child. Updates handle this too. const primaryChildFragment = fiber.child; const fallbackChildFragment = primaryChildFragment ? primaryChildFragment.sibling : null; const fallbackChild = fallbackChildFragment ? fallbackChildFragment.child : null; if (fallbackChild !== null) { mountFiberRecursively( fallbackChild, shouldIncludeInTree ? fiber : parentFiber, true, traceNearestHostComponentUpdate, ); </del> <ins> const isSuspense = fiber.tag === ReactTypeOfWork.SuspenseComponent; if (isSuspense) { const isTimedOut = fiber.memoizedState !== null; if (isTimedOut) { // Special case: if Suspense mounts in a timed-out state, // get the fallback child from the inner fragment and mount // it as if it was our own child. Updates handle this too. const primaryChildFragment = fiber.child; const fallbackChildFragment = primaryChildFragment ? primaryChildFragment.sibling : null; const fallbackChild = fallbackChildFragment ? fallbackChildFragment.child : null; if (fallbackChild !== null) { mountFiberRecursively( fallbackChild, shouldIncludeInTree ? fiber : parentFiber, true, traceNearestHostComponentUpdate, ); } } else { let primaryChild: Fiber | null = null; const areSuspenseChildrenConditionallyWrapped = OffscreenComponent === -1; if (areSuspenseChildrenConditionallyWrapped) { primaryChild = fiber.child; } else if (fiber.child !== null) { primaryChild = fiber.child.child; } if (primaryChild !== null) { mountFiberRecursively( primaryChild, shouldIncludeInTree ? fiber : parentFiber, true, traceNearestHostComponentUpdate, ); } </ins> } } else { <del> let primaryChild: Fiber | null = null; const areSuspenseChildrenConditionallyWrapped = OffscreenComponent === -1; if (areSuspenseChildrenConditionallyWrapped) { primaryChild = fiber.child; } else if (fiber.child !== null) { primaryChild = fiber.child.child; } if (primaryChild !== null) { </del> <ins> if (fiber.child !== null) { </ins> mountFiberRecursively( <del> primaryChild, </del> <ins> fiber.child, </ins> shouldIncludeInTree ? fiber : parentFiber, true, traceNearestHostComponentUpdate, ); } } <del> } else { if (fiber.child !== null) { mountFiberRecursively( fiber.child, shouldIncludeInTree ? fiber : parentFiber, true, traceNearestHostComponentUpdate, ); } } // We're exiting this Fiber now, and entering its siblings. // If we have selection to restore, we might need to re-activate tracking. updateTrackedPathStateAfterMount(mightSiblingsBeOnTrackedPath); </del> <ins> // We're exiting this Fiber now, and entering its siblings. // If we have selection to restore, we might need to re-activate tracking. updateTrackedPathStateAfterMount(mightSiblingsBeOnTrackedPath); </ins> <del> if (traverseSiblings && fiber.sibling !== null) { mountFiberRecursively( fiber.sibling, parentFiber, true, traceNearestHostComponentUpdate, ); </del> <ins> fiber = traverseSiblings ? fiber.sibling : null; </ins> } }

Discussion:
Describe what you were doing when the bug occurred: Please do not remove the text below this line DevTools version: 4.11.0- Call stack: at chrome- at Map.forEach (<anonymous) at RankedChartBuildergetChartData (chrome-) at ProfilingCacheProfilingCache.getRankedChartData (chrome-) at CommitRankedAutoSizer (chrome-) at Rh (chrome-) at Ci (chrome-) at uk (chrome-) at tk (chrome-) at qk (chrome-) Component stack: at CommitRankedAutoSizer (chrome-) at div at div at div at SettingsModalContextController (chrome-) at ProfilerProfiler (chrome-) at ErrorBoundaryErrorBoundary (chrome-) at PortaledContent (chrome-) at div at div at ProfilerContextController (chrome-) at TreeContextController (chrome-) at SettingsContextController (chrome-) at ModalDialogContextController (chrome-) at DevTools_DevTools (chrome-)
It doesn't look like this bug report has enough info for one of us to reproduce it. Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. Screenshots or videos can also be helpful if they help provide context on how to repro the bug. Here are some tips for providing a minimal example:
Just saw this same stacktrace running devtools . I don't know how to reproduce it, so I'm not gonna open a new issue. Call stack: Component call stack: My id was 397.
The only thing I was doing was hitting right arrow key on this thingy to scroll through my rerenders. !
Ah! (sorry to triple post!) I can reproduce it most of the time by clicking on items in the high thirties for this profile:

Describe what you were doing when the bug occurred: on commits greater than 3s through the commits doing a next next Please do not remove the text below this line DevTools version: 4.10.1- Call stack: at updateTree (chrome-) at getCommitTree (chrome-) at ProfilingCacheProfilingCache.getCommitTree (chrome-) at CommitFlamegraphAutoSizer (chrome-) at Hh (chrome-) at qi (chrome-) at mk (chrome-) at lk (chrome-) at kk (chrome-) at ck (chrome-) Component stack: at CommitFlamegraphAutoSizer (chrome-) at div at div at div at SettingsModalContextController (chrome-) at ProfilerProfiler (chrome-) at ErrorBoundaryErrorBoundary (chrome-) at PortaledContent (chrome-) at div at div at ProfilerContextController (chrome-) at TreeContextController (chrome-) at SettingsContextController (chrome-) at ModalDialogContextController (chrome-) at DevToolsDevTools (chrome-)
Can you reliably reproduce this? If so, can you please share a repro case with us? (The bug is unlikely to be fixed without out.)
Should I be providing the profiler json? Because using a recording profiler json or the use case, I mentioned above, it reproduces always. Or are you looking for a repository where this can be reproduced?
Ah, sorry my original request was unclear. No, profiler JSON would likely just show that an element is indeed missing. A repro case (where I can run the code, see where/how/why DevTools misses the element) is what I need to fix.
Argh. So this is going to sound weird. I have a project where I can reproduce this, and I can do that always (see the date @ screenshot) but I can't ship it out due to a lot of internal tooling. So, I tried a similar use-case in my and I cannot it reproduce in that . I'll try some more and see if I can reproduce it in my personal project. The image below is from the project which I can't ship !
I would be willing to sign an NDA or similar agreement if that would help. Otherwise, it would be super helpful if you were able to reduce it to something that you could ship. (Maybe you could start with your full app and remove things until you get to the smallest case that repros the bug?

Then you could share just that?)
Friendly ping. Any update or chance of one?
Hey try the below: Use this repo . The movie attached should help w/ repro steps. I also left some silly comments in - if you wanna try those out as well (somehow I feel they contribute to this trace - I could be wrong there). I haven't experimented much w/ the different yarn, node and npm versions, but below the ones which kinda did it. https://user-
Thank you for the repro! Holiday time so I might not take a look right away, but I'll try to look soonish.
I knew there will be so many edge cases for these unfound fiber errors Anyway, based on repro, the problem (for this case) is that there's a error thrown I think by the recursive function due to the big number of elements that it needs to mount. I reproduced it in . Here's the steps to reproduce it: profiling Show button Hide button profiling
That's good insight. Can confirm this on my side as well, (though only if I disable the host component filter). My intuition when writing DevTools was that it would be very uncommon for apps to have React trees deep or wide enough that the recursive function (or similar functions, e.g. ) would run out of stack. I think that's true, but given how large the user base is I guess it makes sense that it happens sometimes. I took a stab at rewriting the recursive methods in the backend/renderer in but didn't get them all (, , , ) because it would have been a big change and would make the code harder to read. Maybe worth picking back up and finishing that effort. Anyone interested? The good news is, DevTools has decent unit test coverage.
Hi I may not be able to start till next week, but I'd like to give it a shot if you're cool with it
Sounds great Keep me posted.
Friendly ping on this. Had the same issue multiple times and fallback to console log debugging
Circling back around to this. Using the excellent repro steps () shared by I can repro this faster if I change the default items (in ) from to .

Then just loading the app, I notice the following error (in the console): If I ignore this error and profile anyway: the number of list items from 5,000 -0 several errors (in the DevTools extension console, likely caused by the stack overflow above): profiling an error now in DevTools UI (related to the previous errors): So the underlying cause here, as pointed out by is the original stack overflow error.
Converting all of the recursive methods in DevTools to be iterative would be a bit lift but I think I can fix this particular case by iterating over siblings rather than recursing. I'll post a PR shortly.