-fsanitize=undefined, and some fishy commits

Stephan Bergmann sbergman at redhat.com
Thu Mar 5 02:58:06 PST 2015

LO master now successfully passes "make check" under 
-fsanitize=undefined (which instruments the C/C++ code to do various 
runtime checks for undefined behavior; see 
for enabling it in LO).

However, I had to commit a handful of somewhat fishy changes to make 
that work, all revolving around bad downcasts of class pointers.  Most 
of them are in the context of destroying an object of derived class D, 
having reached the destructor of base class B (so "this" no longer 
points to a D, only to a B), but then the destructor of B calling out to 
some code that invalidly downcasts from B to D.  What is most fishy 
about those cases is whether it makes sense at all to do any substantial 
computation from a destructor (which parts of our code base are infamous 
for, though).

Therefore, I would appreciate it if others could take a look at those 
commits (all the commit messages contain backtrace excerpts):

* vcl:

"Hack to make an in-destruction SystemWindow no longer claim to be one"

* sc:

"Hack to work around an in-destruction ScStyleSheetPool no longer being one"

* sw:

"Hack to make an in-destruction SwFlyFrm no longer claim to be one"

"Hack to make an in-destruction SwFlyInCntFrm no longer claim to be one"

"Hack to make an in-destruction SwPageFrm no longer claim to be one"

"Hack to work around an in-destruction SwTxtNode no longer being one"

"Avoid bad downcast of SwFrmFmt to SwSectionFmt" (where the SwFrmFmt 
appears to be a genuine SwFrmFmt instance, not an in-destruction 
SwSectionFmt one?)

More information about the LibreOffice mailing list