Runtime signal connection errors when using the new signal style

[Manuel de la Peña]

In the ubuntu download manager we are using the new connection style syntax (http://qt-project.org/wiki/New_Signal_Slot_Syntax) so that if there are errors in the signal connections we will be notified at compile time. However, in recent versions of udm we have noticed that the udm tests that ensure that the qt signals are emitted correctly have started failing randomly in the build servers.

As it can be seen in the following build logs the compilation does finish with no errors but the tests raise errors at runtime (an assert was added for each of the connect calls in the project):

https://launchpadlibrarian.net/172280588/buildlog_ubuntu-trusty-powerpc.ubuntu-download-manager_0.3%2B14.04.20140408.1-0ubuntu1_FAILEDTOBUILD.txt.gz
https://launchpadlibrarian.net/172280333/buildlog_ubuntu-trusty-arm64.ubuntu-download-manager_0.3%2B14.04.20140408.1-0ubuntu1_FAILEDTOBUILD.txt.gz
https://launchpadlibrarian.net/172280872/buildlog_ubuntu-trusty-armhf.ubuntu-download-manager_0.3%2B14.04.20140408.1-0ubuntu1_FAILEDTOBUILD.txt.gz

Some of the errors between the diff archs are the same but this feels like a coincidence. The unity-scope-click package project has had the same issue and has solved it in the following way:

scope/click/download-manager.cpp (123)

 // NOTE: using SIGNAL/SLOT macros here because new-style
    // connections are flaky on ARM.
    c = connect(impl->systemDownloadManager.data(), SIGNAL(downloadCreated(Download*)),
                this, SLOT(handleDownloadCreated(Download*)));

    if (!c) {
        qDebug() << "failed to connect to systemDownloadManager::downloadCreated";

    }

It is very interesting that the tests have never (so far) failed in the other 2 architectures (i386, amd64). I'm raising this issue because it might be hitting us in some other projects.

PS: I'm reporting this error here after talking with zoltan but I think is something that should be taken upstream or in qt5core5.

[Manuel de la Peña (mandel)]

This is very informative: https://lists.launchpad.net/ubuntu-phone/msg07574.html

[Dmitry Shachnev (mitya57)]

According to that mail, https://codereview.qt-project.org/81095 should fix it.

Timo, do you think we can cherry-pick that change in the next upload (in our case, it will disable -Bsymbolic* on everything but i386 and amd64).

[Timo Jyrinki (timo-jyrinki)]

It should be suitable if it passes testing, so scheduling to be landed when U-series opens.

[Timo Jyrinki (timo-jyrinki)]

Additional notes from IRC:
< cjwatson> Disabling -Bsymbolic on armhf has potential significant performance effects for process startup, so I think we should try to avoid it if we can
< cjwatson> Or rather -Wl,-Bsymbolic-functions, I guess you mean
< cjwatson> Perhaps worth verifying my intuition about what effect it actually has
< cjwatson> But Qt seems like exactly the sort of hot spot that -Bsymbolic-functions is best at

So maybe not a good idea necessarily on armhf.

See also the suggestions in the upstream bug report https://bugreports.qt-project.org/browse/QTBUG-36129 to try '-pie -fPIE', would it workaround this problem on an app basis?

[Tim Peeters (tpeeters)]

not an uitk bug

[Launchpad Janitor (janitor)]

[Expired for qtbase-opensource-src (Ubuntu) because there has been no activity for 60 days.]