How We (Almost) Found Chromium's Bug via Crash Reports to Report URI
文章讲述了开发团队如何通过启用崩溃报告工具Report URI,最终发现并修复了一个由新增CSP指令引发的低级错误(SIGILL),强调了及时监控和分析的重要性。 2025-10-27 09:9:21 Author: www.troyhunt.com(查看原文) 阅读量:9 收藏

Tracking down bugs in software is a pain that all of us who write code must bear. When we're talking about outright errors in a web page, you typically have something to get you started (such as output in the console), but that wasn't the case here:

Sure! Reboots don't help :) Here are the two error screens which show up. pic.twitter.com/w2dmZcVyHk

— Peter Vogel (@PeterVogel) July 11, 2025

That's on a Chromebook, and it's the first user report we had about the issue back in early July. The initial problem this presented is that there are not a lot of people running around with devices we could test on. But there are enough people using them that we had multiple similar reports, so we were well beyond just giving people like Peter a bit of "works on my machine", and moving on. But the "SIGILL" error means that something pretty low-level has happened and, as you can see from the screen grab, you can't exactly just pop open the dev tools and peak at what's broken in the site when it can't even load in the first place.

However, after months of making no progress whilst the occasional Chromium user popped their head up and reported exactly the same problem, the answer finally emerged:

Reading MDN docs I don't find a directive 'report-sha256', so tried only removing that, and no crash.

— Mark : 1x Software Artisan (@virullius) October 24, 2025

Uh... shouldn't a browser just ignore a directive it doesn't recognise? (And incidentally, report-sha256 is documented in CSP level 3.) But the timing was awful coincidental with when we added that exact directive, only just before people started reporting problems:

Wow, good sleuthing! The timing of when this first began aligns with this commit from @stebets. I've just dropped it, does it look ok now? Also CC'ing @Scott_Helme - you seen this before mate? Bug was logged here: https://t.co/wiKpdmSxhU pic.twitter.com/m2nsDtAMjB

— Troy Hunt (@troyhunt) October 24, 2025

Getting to the title of this post, we almost worked this out ourselves, we just didn't look at data that was right in front of our eyes. Here it is:

This is Report URI's crash report graph, and until June, we'd had a good run! Crash reports are super cool because your customers' browsers automatically generate them, and with just a little tweaking of your response headers, you can easily turn your customers into automatic crash reporting bots! Report URI's value proposition (disclosure: I have a working relationship with them) is that it can receive those reports and create graphs like you see above. We just weren't watching the reports closely enough, hence the "almost" in the title.

I wanted to write this short post because sometimes, the answer is right in front of your eyes, and if we'd looked at what in hindsight is a really obvious place to check, we would have nailed this months ago. So, turn on crash reporting, and pay attention to it!

Report URI
Tweet Post Update Email RSS

Hi, I'm Troy Hunt, I write this blog, create courses for Pluralsight and am a Microsoft Regional Director and MVP who travels the world speaking at events and training technology professionals


文章来源: https://www.troyhunt.com/how-we-almost-found-chromiums-bug-via-crash-reports-to-report-uri/
如有侵权请联系:admin#unsafe.sh