While working with one of the larger websites we manage, we ran into a problem that needed debugging. Some of the WordPress back-end pages of the site would fail to load with the following error message.
Aw, Snap!
Something went wrong while displaying this webpage.
Error code: 5
This page load failure was happening in the Brave browser, which is based on Chromium. Testing the same pages in FireFox and Safari both worked fine, so it appeared to be a bug in the browser, rather than an issue with the website itself.
I have an extensive background in both software development and beta testing commercial software. I was the number one beta tester for LightWave 3D for many years (while they tracked number of bugs successfully isolated and reported) and a top beta tester for Macromedia Director and Aldus FreeHand before that. Based on my beta testing experience, I figured that if I could isolate and report this bug in the web browser, the developers could fix it in a future version. So, I set about pinpointing the bug.
The website is a large WordPress multi-site with over 5,000 sub-sites. The site uses a WordPress plugin that creates various maintenance forms populated with pop-up select menus for each sub-site in the network. So, in this large network the forms can reach over 5,000 pop-up fields. With such large forms, I suspected a memory management problem, memory leak or a time-out hanging the browser. The computer I was testing on has 64GB of RAM and other browsers have no problem opening the page, so it wasn’t running out of actual memory, most likely the browser was just managing it poorly. I had successfully used an earlier version of a Chromium browser (Dissenter) on the problem pages before. So, I expected a Chromium update introduced a memory management bug somewhere along the way.
In order to further isolate the browser bug, without causing any potential problems on the live site, I created a mock-up test page with a form consisting of 3K dummy select input fields. I used this test page to test other browsers and perform regression testing with various older versions of the Chromium browser.
Results of Initial Testing on Mac OS X (Sierra at the time)
- Brave 1.33.106 based on Chromium 96.0.4664.110 hangs
- FireFox 95.0.1 (64-bit) works
- Safari Version 12.1.2 (12607.3.10) works
- Dissenter 0.70.122 based on Chromium 78.0.3904.87 works
Results of Backtesting Earlier Versions of Chrome/Chromium to Isolate Where it Broke
- Chromium Version 90.0.4430.0 (Developer Build) (x86_64) Goes through 9 waits and eventually draws in about 2:52.
- Chromium Version 91.0.4472.0 (Developer Build) (x86_64) Goes through 6 waits and eventually draws in about 2:50.
- Chromium Version 92.0.4515.0 (Developer Build) (x86_64) Goes through 6 waits and then hangs with Aw, Snap! Error code: 5 after about 2:23.
- Chromium Version 93.0.4577.0 (Developer Build) (x86_64) hangs with Aw, Snap! Error code: 5 after about 2:10.
So, it looks like it broke on Chrome/Chromium version 92 and later. None of those versions can draw the page, where current versions of FireFox and Safari can draw the page without any problems.
Submitted Chromium Bug Report and Ultimate Resolution
Once I isolated Chromium version 92 as the culprit, I submitted an official bug report to the Chromium project, so that the developers would be able to fix the bug. Unfortunately, it looks like they don’t actually intend to fix the problem, apparently because the bug is in a new memory management component, PartitionAlloc. They switched to that memory module for better memory security. That’s a little ironic, because crashing bugs are sometimes flaws that hackers exploit as attack vectors to compromise software. So, I would think they would want to fix it, which was why I bothered to isolate and report it for them in the first place.
Bug Report
Chrome Version : 92.0.4515.0 (Developer Build) (x86_64) and later on Mac OS X 10.12.6
URLs (if applicable) : https://dreamlight.com/google-chrome-test-form/
Other browsers tested:
Safari: OK
Firefox: OK
Edge: FAIL
What steps will reproduce the problem?
(1) Visit this test page: https://dreamlight.com/google-chrome-test-form/
(2) Keep clicking through the browser’s “wait” messages.
(3) Eventually fails with Aw, Snap! Error code 5
What is the expected result? Takes a while but draws the page like other browsers, and like versions of Chromium prior to version 92.
What happens instead? Aw, Snap! Error code 5
Bug Report Resolution
Could your website or brand use an update or redesign? Contact us for an estimate to design an award-winning new website and/or to reinvigorate your brand!
This is an OutOfMemory crash, probably after the switch to PartitionAlloc that provides much better memory safety for increased security.
Received signal 4 ILL_ILLOPN 7fe651b7a800
#0 0x7fe651c256d9 base::debug::CollectStackTrace()
#1 0x7fe651b1ea93 base::debug::StackTrace::StackTrace()
#2 0x7fe651c25161 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#3 0x7fe640a903c0 (/lib/x86_64-linux-gnu/libpthread-2.31.so+0x153bf)
#4 0x7fe651b7a800 base::internal::OnNoMemoryInternal()
#5 0x7fe651b7a819 base::TerminateBecauseOutOfMemory()
#6 0x7fe651c6b8d6 OnNoMemory()
#7 0x7fe63d976e16 WTF::PartitionsOutOfMemoryUsing2G()
#8 0x7fe63d96840d WTF::Partitions::HandleOutOfMemory()
#9 0x7fe651c7ef4b base::PartitionRoot<>::OutOfMemory()
#10 0x7fe651c7b03c base::internal::(anonymous namespace)::PartitionOutOfMemoryCommitFailure<>()
#11 0x7fe651c74145 base::internal::(anonymous namespace)::PartitionDirectMap<>()
#12 0x7fe651c6e129 base::internal::PartitionBucket<>::SlowPathAlloc()
#13 0x7fe63d96a8d7 WTF::Partitions::BufferMalloc()
#14 0x7fe6478e2826 WTF::VectorBufferBase<>::AllocateBufferNoBarrier()
#15 0x7fe6478e2dc1 WTF::Vector<>::ReallocateBuffer()
#16 0x7fe6478e0c10 blink::NGFragmentItemsBuilder::AddLine()
…