I'm going to need rounding for large allocation sizes like jemalloc to work around poorly written applications and libraries with element-by-element realloc growth loops. GTK+ / Qt ecosystems are full of memory corruption & inefficient patterns like this.
github.com/AndroidHardeni
Conversation
It's all fine with server and command-line applications and on Android, but GTK+ and Qt applications often take a ridiculously long time to load because applications feel like reallocating 32 bytes to 32 MiB via realloc loops in increments of 32 bytes. Krita is particularly bad.
2
2
8
Epiphany does a lot of this but it's also packed full of memory corruption so it's hard to test performance... not that anyone should be using such an insecure browser anyway. Even Firefox's lack of meaningful sandboxing and other issues are way less bad than the WebKitGTK mess.
2
4
I find it shocking how poorly desktop Linux applications other than Firefox/Chromium hold up to being run with memory corruption mitigations. It's ridiculous to use C or C++ without any ASan/UBSan testing in 2019. Qt forces lots of undefined behavior in the framework itself...
2
6
13
Replying to
I went to qtcon to give a talk and tell them that, I guess it hasn't helped...
1
2
Replying to
I do think they are doing some testing with ASan, probably not much with UBSan though, and it's definitely not enough to avoid a backlog of obvious bugs triggered during regular use without even doing any fuzzing. Qt has some deeply ingrained cases of UB like bad casting too.
1
For the most part, it's GNOME applications where I'm actually seeing non-benign memory corruption in regular use. Epiphany/WebKitGTK has some serious issues. It crashes when the slab allocator uses guard slabs which it does in the default configuration due to out of bounds reads.