I only tried to get Qt Base up and running. But Qt Declarative will be next, after Qt Base.

That would be awesome (:

AFAIK Fil-C does not catch all memory safety bugs, for example some use-after-free are just not bugs but work as intended (you still access the original data/allocation). This means that it's not a sanitizer and code that runs fine on Fil-C may show UB when run normally.

> for example some use-after-free are just not bugs but work as intended (you still access the original data/allocation)

That doesn't sound right? For example, from the Fil-C GC docs [0]:

> If you call `free`, the runtime will flag the object as free and all subsequent accesses to the object will trap. Additionally, FUGC will not scan outgoing references from the object (since they cannot be accessed anymore).

[0]: https://fil-c.org/fugc

Any use after free is a bug. There is no way you can use that area without ownership.

eh, I daily-drive a -fsanitize=address -fsanitize=undefined build of Qt and actual memory bugs are almost never a thing - I think the only time I had some were in tooling executables such as qmllint, but not in the framework itself. Most of the bugs by large are more "behaviour" bugs.

I’m impressed that QT runs clean enough under ubsan for daily use.

ubsan definitely has some warnings due to a few "technically UB" patterns used as optimizations in Qt as they are known-working on every target platform under the sun, but yeah, no crashes :)

I'm only using this configuration for the software I develop though (+ libc++ debug mode) as it's painfully slow, but it exercises the Qt codebase in depth.

Here is another bug that led to crush thatt I reported while developing my block editor:

https://qt-project.atlassian.net/browse/QTBUG-124572

Good to know! Which version of Qt are you using?

I regularly update, right now 6.10.1 + a few patches

Depends in which sense you want it to "catch" the bugs. As this readme notes/quotes,

> All memory safety errors are caught as Fil-C panics.

If your problem is a memory-based bug causing a crash, I think this would just... catch the memory-based bug and crash. Like, it'd crash more reliably. On the other hand, if you want to find and debug the problem, that might be a good thing.

Sure, if the memory error is an immediately crashing one like a null per deref, but if is (for example) a memory corruption (e.g. an out of bounds write or a write-after-free) then this would be super helpful in exposing where those are happening at the source.

That’s what “catch” means here. As in, catch it in the act. Tools that make bugs crash more reliably and closer to the source of the problem are extremely valuable.

Half a second's worth is a lifetime of debugging at today's clock rates so the closer to the fault the crash happens the sooner you can fix it.