help understanding a Windows crash report

Dirk Hohndel dirk at hohndel.org
Wed Oct 29 21:19:22 PDT 2014


> On Oct 29, 2014, at 6:50 PM, Thiago Macieira <thiago at macieira.org> wrote:
> 
> I'm fairly certain it's not a Qt bug now. This is a binary incompatibility 
> issue between QtGui and QtWidgets due either a bug in Dirk's packaging or in 
> Fedora's packaging.
> 
> Dirk: verify that the DLLs you gave me are exactly the ones that Fedora 
> shipped. If they are, the bug is in Fedora's build, somehow. It looks like a 
> stale Qt5Gui.dll got packaged instead of the right one.

I am 99% certain that the package I gave you had the correct DLLs from the
Fedora packages. I’ll need to hunt down the md5 values for those DLLs to be
100% sure.

> Explanation:
> 
> The backtrace that I managed to obtain with Dirk made little sense, but after 
> realising that the debugger wasn't picking up the names of unexported 
> functions, I reconstructed the following backtrace:
> 
> #3 QPlatformFontDatabase::resolveFontFamilyAlias(const QString &) const
> #4 QFontComboBoxPrivate::_q_updateModel()
> [not shown] QFontComboBox::setWritingSystem(QFontDatabase::WritingSystem)
> #5 QFontComboBox::QFontComboBox(QWidget *)
> 
> If you look at _q_updateModel, you'll see that it does not call 
> resolveFontFamilyAlias. But by comparing the assembly with the source code, 
> the crash point is on line:
> 
>        if (pfdb->isPrivateFontFamily(list.at(i)))
> 
> pfdb is a QPlatformFontDatabase.
> 
> Here's how I know it's a BIC issue: both resolveFontFamilyAlias and 
> isPrivateFontFamily are virtual functions and isPrivateFontFamily was added 
> between Qt 5.3.1 and 5.3.2, inserted just before resolveFontFamilyAlias. That 
> means the caller in QtWidget placed a call to the correct virtual slot, but 
> the QPlatformFontDatabase's virtual table in QtGui contained the old function 
> at that position.

Excellent investigation. I’m impressed.

> This problem cannot happen in a clean build. The only way for this to happen 
> is if Fedora rebuilt without cleaning up the .o files or if they accidentally 
> packaged a pre-release Qt5Gui.dll.

Their build system should prevent this from happening. But then that’s not
optimized for cross building, I guess. I’m on my Mac, creating a daily Mac
build right now, once I’m done with that I’ll look at the DLLs on the Fedora box.

Thanks for figuring this out, Thiago.

/D


More information about the subsurface mailing list