Patching Qt5Network for Christmas

Qt5 and KDE Plasma 5 have been running smoothly on my workstation desktop for a year or more. I have a kind of boring desktop: there is one CPU, one graphics card, two network interfaces, and I use the default settings for just about everything. .. and everything (that I need) just works.

But it didn’t work for everyone: there was this one weird bug report that when the system had VLANs defined, that most Qt5-based applications would crash or refuse to start up. That first manifested itself there as a build failure of kf5-syntaxhighlighting. After some discussion with Volker, I ended up with a workaround: don’t validate the schema’s during the build. That takes away the networking dependency, and things were OK again.

Other similar bug reports trickled in. They’re now all closed as duplicates of this original. Some patches trickled in, which I didn’t particularly like because they were of the “comment this bit out and things work”. Thankfully the original reporter of the kf5-syntaxhighlighting build failure, Ting-Wei Lan, did a great deal of debugging work. Enough to give me a handle on where to continue looking. I hemmed and hawed, tried blaming the run-time loader, but really all the evidence pointed at memory corruption from inside Qt5Network.

Fortunately the problem was totally reproducible and consistent in the way it crashed: create a VLAN, and one by one all Qt-based applications that touch the network would crash with an unresolved symbol. Rebuilding with debug symbols and everything turned on .. just got me a core dump somewhere else. After much futzing about, I found one location where adding a qWarning() << "foo"; made the problem go away. That's just as unsatisfying as commenting-out bits until it works.

Valgrind to the rescue. It told me about uninitialized memory being used in ioctl() calls, in an area of Qt5Network that I already thought was a bit flaky (wrt. FreeBSD support, anyway).

En passant I learned more about gdb, valgrind, ioctl() internals, and network status querying. And on Christmas Eve (or afternoon) I finally landed a bunch of patches:

  • Network bearer detection fixed; Ethernet is now recognized as such and doesn't hit the generic bearer.
  • Network media detection fixed; don't re-use ioctl buffers for a different ioctl; use the right ioctl number (apparently NetBSD and FreeBSD differ there).
  • Be slightly smarter about closing sockets; I took this opportunity to introduce a SockPuppet class, for silliness.
  • Support LibreSSL, OpenSSL 1.0, and OpenSSL 1.1 all at the same time.

The last item, supporting different SSL implementations, is all other people's work. I just built, tested and landed their efforts. Credits are in the corresponding ports commits.

As a consequence of all this, along with the release of FreeBSD 12.0, I now have an i3-based FreeBSD 12 machine with up-to-date Intel graphics and a KDE Plasma 5 desktop that uses libressl across the entire stack, and can survive having VLANs modified, as well. That's a good present for the end of the year. (For the new year, I resolve to try to upstream some of these fixes, minus any silliness)

2 thoughts on “Patching Qt5Network for Christmas

    • No, it’s not about where the schemas live. They are properly namespaced and can be properly found; the issue is that the code that is supposed to load the schema’s (from anywhere) has a dependency on Qt5Network, which falls over in the presence of VLANs (or, used to).