Crash ID: 68a5eafcfe67bb44

 	WTF::Partitions::FastMalloc
>	blink::ComputedStyle::Create
 	blink::StyleResolver::StyleForElement
 	blink::Element::StyleForLayoutObject
 	blink::Element::RecalcOwnStyle
 	blink::Element::RecalcStyle
 	blink::ContainerNode::RecalcDescendantStyles
 	blink::Element::RecalcStyle
 	// the previus two lines repeated 10 times
 	blink::Document::UpdateStyle()

Bisect info: 563609 (good) - 563613 (bad)
https://chromium.googlesource.com/chromium/src/+log/d30e0da3..70ddf623?pretty=fuller
Suspecting 6b92fcfb1cf296130f6cb38213aa52a0324c9e46 "Do not reset NavigationRequest in DidStopLoading"
A per-revision bisect would be helpful here, probably, because it's not obvious.
Landed in 69.0.3448.0

Unable to reproduce this issue on Windows 10 (laptop - Lenova ThinkPad) with chrome #69.0.3452.0  as per steps mentioned in the comment #0, because of this unable to run the per-revision bisect script.

As per comment #2, assigning it to suspected CL owner

clamy@ Could you please into this issue...

List of builds:
===============
69.0.3463.0	20.00%	1
69.0.3457.2	20.00%	1
69.0.3455.0	20.00%	1
69.0.3453.0	20.00%	1
69.0.3451.0	20.00%	1

Thank You...

Reproduces easily (every other attempt) though not always on Version 69.0.3465.0 (Official Build) canary (64-bit).
Crash ids: ea065e925b2d5e5d, d83de723b1a49de9 

For reproduction, click the link under the big date. See attached image

Deleted: ynetprob.png 986 KB

	ynetprob.png 986 KB View Download

I could not repro on trunk. Based on my the stack you've shown, it's unlikely to be caused by my CL, as the issue seems to be related to styling, which my CL doesn't touch at all. In fact, given that we crash during a memory allocation, this could be an out-of-memory issue.

Another crash 5377c511eb1c9bf3 with a similar call stack ended on strlen() so the problem is not OOM, apparently.

Narrowed bisect info using x64 snapshots: 563609 (good) - 563612 (bad)
https://chromium.googlesource.com/chromium/src/+log/d30e0da3..a5aeaba1?pretty=fuller

Even now with only three commits it's not any more obvious so a per-revision bisect is still desirable.

I got 563609 (good) - 563611 (bad) running tool/bisect-builds on Linux64. I don't get a crash, but a blank page. That really sounds like it is https://crrev.com/6b92fcfb1cf296130f6cb38213aa52a0324c9e46

I can reproduce this consistently on chrome target built from master (Linux64) as well. The suspected revision did not revert cleanly, and I don't know how to resolve those conflicts. clamy@, could you try to reproduce the blank back navigation and possibly try to revert your change locally to see if that changes anything?

Was able to revert after all. Not sure if I did it correctly, but it made the back navigation work again. So there's definitely something wrong with https://crrev.com/6b92fcfb1cf296130f6cb38213aa52a0324c9e46

I went back to this bug, and I can't repro the crash or blank page on trunk anymore.

re #9: the site could have implemented a workaround.
Some developers do it even for Canary (I do).

Unfortunately, without a repro I cannot debug the issue. Will close this bug in the meantime.