5 ms·

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/QTBU

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 https://qt-project.atlassian.net/browse/QTBUG-122658

cristianadam 9mo ago
I only tried to get Qt Base up and running. But Qt Declarative will be next, after Qt Base.
- rubymamis 9mo ago
  That would be awesome (:
yjftsjthsd-h 9mo ago
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 9mo ago
  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 9mo ago
  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.
- jacquesm 9mo ago
  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.
jcelerier 9mo ago
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 9mo ago
  I’m impressed that QT runs clean enough under ubsan for daily use.
  - jcelerier 9mo ago
    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.
- fransje26 9mo ago
  Good to know! Which version of Qt are you using?
  - jcelerier 9mo ago
    I regularly update, right now 6.10.1 + a few patches
- rubymamis 9mo ago
  Here is another bug that led to crush thatt I reported while developing my block editor: https://qt-project.atlassian.net/browse/QTBUG-124572 https://qt-project.atlassian.net/browse/QTBUG-124572
SkiFire13 9mo ago
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 9mo ago
  > 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 https://fil-c.org/fugc
- jacquesm 9mo ago
  Any use after free is a bug. There is no way you can use that area without ownership.

cristianadam 9mo ago

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

rubymamis 9mo ago
That would be awesome (:

yjftsjthsd-h 9mo ago

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 9mo ago
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 9mo ago
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.
jacquesm 9mo ago
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.

jcelerier 9mo ago

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 9mo ago
I’m impressed that QT runs clean enough under ubsan for daily use.
- jcelerier 9mo ago
  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.
fransje26 9mo ago
Good to know! Which version of Qt are you using?
- jcelerier 9mo ago
  I regularly update, right now 6.10.1 + a few patches
rubymamis 9mo ago
Here is another bug that led to crush thatt I reported while developing my block editor: https://qt-project.atlassian.net/browse/QTBUG-124572 https://qt-project.atlassian.net/browse/QTBUG-124572

SkiFire13 9mo ago

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 9mo ago
> 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 https://fil-c.org/fugc
jacquesm 9mo ago
Any use after free is a bug. There is no way you can use that area without ownership.