Runtime signal connection errors when using the new signal style

Bug #1304709 reported by Manuel de la Peña
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu UI Toolkit
Invalid
Undecided
Unassigned
qtbase-opensource-src (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

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.

Revision history for this message
Manuel de la Peña (mandel) wrote :
Revision history for this message
Dmitry Shachnev (mitya57) wrote :

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).

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

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

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

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?

Changed in qtbase-opensource-src (Ubuntu):
status: New → Incomplete
Revision history for this message
Tim Peeters (tpeeters) wrote :

not an uitk bug

Changed in ubuntu-ui-toolkit:
status: New → Invalid
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in qtbase-opensource-src (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers