> On Oct 29, 2014, at 6:50 PM, Thiago Macieira <[email protected]> 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 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
