New "Uncovered Lines" Visualization for -WUnsafe-buffer-usage

30 views
Skip to first unread message

Arthur Sonzogni

unread,
Sep 22, 2025, 2:41:27 AM (9 days ago) Sep 22
to memory-safety-dev, David Adrian, Tom Sepez, danakj

Hi @memory-safety-dev

Following a discussion with @David Adrian about estimating the amount of code running behind -WUnsafe-buffer-usage, I've added a new visualization to the Commit Tracker.

This new dataset tracks the actual uncovered line over time and across directories. It excludes comments, macros, and empty lines.

Here's the new view of uncovered lines.

image.pngimage.png

80% of the uncovered lines in the chromium repository are in third party libraries.

This is an improvement on the previous dataset, which only tracked the opt-outs (#pragma allow_unsafe_buffer_usage and UNSAFE_TODO):
image.png


As you know, we enabled -WUnsafe-buffer-usage by default almost everywhere (ref: google.com thread), and Tom Sepez later did the great work of migrating a lot of file-level #pragma allow_unsafe_buffers  into instruction-level UNSAFE_TODOs.

However, the mix of directory-level exclusion lists, file-level pragmas, and instruction-level macros made it difficult to accurately estimate how much code was actually covered. This new view, which tracks the uncovered lines directly, should fix that.

Let me know what you think. I'm happy to tweak it a bit if needed.

FYI, you can now download the data directly from the UI (see the buttons in the tracker).

Best,
@Arthur Sonzogni 

Nico Weber

unread,
Sep 22, 2025, 9:12:25 AM (8 days ago) Sep 22
to Arthur Sonzogni, memory-safety-dev, David Adrian, Tom Sepez, danakj
Thanks!

I was a bit confused by the visualization. Can you confirm that the following is right?

* The boxes are ordered by the total number of lines in the directory represented by this box (i.e. not number of not covered lines, but number of lines total, covered or not)
* The boxes are colored by the percentage of lines in that directory that opt out of the warning

So e.g. in https://chrome-commit-tracker.arthursonzogni.com/treemap?colormap=Red&colormapMax=0.3&colormapMin=0&field_color=lines_unsafe_buffer_usage&field_size=line&path=third_party,blink,renderer,platform&repositories=chromium&dates=2020-01-01,2025-09-22&history_size=1&exclude_test it's not quickly possible to find the directory with "most work remaining" since it's neither the directory listed first (most lines, but most of them covered, graphics), not the one with the worst ratio (audio, 26%), but one with an unfortunate combination of both (wtf, 4,951/23,608 (21.0%)). Correct?

To get the "80%" figure, you took 2,058,142 from the box and the total 2,486,405 from the graph and manually divided them, yes? Or is that in more explicit form in the diagram somewhere?

Most of the third-party code in the third-party box is "first party third party" code in the sense that it's Google-authored, right?

--
You received this message because you are subscribed to the Google Groups "memory-safety-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to memory-safety-...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/memory-safety-dev/CAH7Q68VzkD6_MVfkmPTvTceJOpUeJn%2BhmsnavgpyOd25UuGqOg%40mail.gmail.com.

Arthur Sonzogni

unread,
Sep 22, 2025, 9:53:28 AM (8 days ago) Sep 22
to Nico Weber, memory-safety-dev, David Adrian, Tom Sepez, danakj

Thanks, Nico. You're correct on all points.

I've included a README to help users, but I'm not sure if it's sufficient. I'd welcome your suggestions for making it clearer.image.png
____

This is dynamic. So one can move metrics between the numerator and denominator. For instance, to sort on the number of uncovered lines, you can put both on the numerator/denominator. It gives:
image.png
image.png
Unfortunately, there are no ways to use a ratio for the size of the rectangle. Only a sum of metrics at the moment. It should be possible to input a formula like in chrome UMA dashboard, but that's not implemented.


Most of the third-party code in the third-party box is "first party third party" code in the sense that it's Google-authored, right?

Those are the ones checked in the chromium repository. Not all of them are authored by google.
It's not entirely clear to me why some third-party libraries are copy-pasted into the git repository while others aren't, but I suspect it's due to local modifications chromium added.
image.png


I might want to add an "Exclude real third-party" checkbox, similar to the existing "Exclude test" one to avoid seeing what we don't fully control.

Kentaro Hara

unread,
Sep 23, 2025, 8:26:36 PM (7 days ago) Sep 23
to Arthur Sonzogni, Nico Weber, memory-safety-dev, David Adrian, Tom Sepez, danakj
This is a great visualization. Thanks Arthur!

Regarding the third_party libraries, do we have any practical plan to reduce unsafe buffer usage? Even if we rewrite code in //third_party/, that will be overwritten by the next rollout. The only viable solution will be to rewrite the original repository. This will be doable for libraries Google is contributing a lot (e.g., grpc, protobuf) but will be hard for others.






--
Kentaro Hara, Tokyo
Reply all
Reply to author
Forward
0 new messages