This is awesome. Would love to see if it catches some of the Qt bugs I found but haven't been resolved yet[1].

[1] https://qt-project.atlassian.net/browse/QTBUG-122658

SkiFire13 2 hours ago | parent | next [-]

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.

	▲	aw1621107 2 hours ago \| parent [-]
		> 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

▲

cristianadam 3 days ago | parent | prev | next [-]

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

	▲	rubymamis 3 days ago \| parent [-]
		That would be awesome (:

▲

jcelerier 6 hours ago | parent | prev | next [-]

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.

▲

adrianN 6 hours ago | parent [-]

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

	▲	jcelerier 5 hours ago \| parent [-]
		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.

▲

yjftsjthsd-h 8 hours ago | parent | prev [-]

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.

	▲	dafelst 8 hours ago \| parent \| next [-]
		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.
	▲	wat10000 7 hours ago \| parent \| prev [-]
		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.