qtsensors crashes on desktop as there is no platform-api backend

Bug #1272294 reported by Rick Spencer on 2014-01-24
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
platform-api (Ubuntu)
High
Martin Pitt
qtubuntu-sensors (Ubuntu)
High
Martin Pitt

Bug Description

Steps:

1. Install qtcreator-sensors
2. Run QtCreator

Result, QtCreator crashes
Expected: a developer can develop against the implemented parts of the API

Note that apps run directly with qmlscene also crash

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: qtubuntu-sensors 0.6+14.04.20140113.1-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-5.20-generic 3.13.0
Uname: Linux 3.13.0-5-generic x86_64
ApportVersion: 2.13.1-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Fri Jan 24 12:36:48 2014
InstallationDate: Installed on 2013-06-18 (220 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130617)
SourcePackage: qtubuntu-sensors
UpgradeStatus: Upgraded to trusty on 2014-01-23 (1 days ago)

Related branches

Martin Pitt (pitti) wrote :

I manually retraced the qmlscene crash file attachment.

The other .crash file for QtCreator does not contain a core dump, so it's useless I'm afraid.

Martin Pitt (pitti) wrote :

Looking at frame #1:

#1 0x00007f4606168e99 in core::SharedAccelerometer::SharedAccelerometer (this=0x7f460636d290 <core::SharedAccelerometer::instance()::instance>, parent=<optimized out>) at /build/buildd/qtubuntu-sensors-0.6+14.04.20140113.1/plugins/sensors/core_shared_accelerometer.cpp:38

This is

      m_accelerometer = ua_sensors_accelerometer_new();

i. e. calling platform-api. Frame #0 is the address NULL, i. e. it tries to call a NULL function. This suggests that the hybris dynloaded bridge in platform-api is not available.

The ProcMaps in the report suggests that you don't use the simulated test sensor backend, as libubuntu-application-api-test1 is not loaded. I suppose you did not run your program under UBUNTU_PLATFORM_API_BACKEND=libubuntu_application_api_test.so.1 UBUNTU_
PLATFORM_API_SENSOR_TEST=/tmp/sensors ?

Martin Pitt (pitti) wrote :

In a configuration when having qtubuntu-sensors installed, but not using the test backend, then qtubuntu-sensors installs the sensor configuration file to use the platform-api backend. But that does not exist on a desktop unless you use the simulated sensor backend. So instead of crashing, it should simply export no sensors at all.

In a configuration where you don't have qtubuntu-sensors installed, the application should work, but of course not get any sensor input. I think that part works, according to Rick on IRC.

Changed in qtubuntu-sensors (Ubuntu):
status: New → Triaged

Correct, when I used the simulated back end the app did run, but also did not crash, at least it did not produce a crash file

Martin Pitt (pitti) on 2014-01-24
summary: - qtsensors doesn't work on desktop
+ qtsensors crashes on desktop as there is no platform-api backend
Martin Pitt (pitti) on 2014-01-30
Changed in qtubuntu-sensors (Ubuntu):
importance: Undecided → High
status: Triaged → In Progress
assignee: nobody → Martin Pitt (pitti)
Martin Pitt (pitti) wrote :

I created a set of tests for this in lp:~pitti/qtubuntu-sensors/crash-without-hw which reproduce the error. The actual crash happens in platform-api's bridge.h:

#define IMPLEMENT_FUNCTION0(return_type, symbol) \
    return_type symbol() \
    { \
        static return_type (*f)() = NULL; \
        DLSYM(&f, #symbol); \
        return f();}

In this situation (desktop without hw sensors/Android) either the bridge itself is NULL or the DLSYM returns NULL, in either case f ends up being NULL and trying to call that will segfault; there is not a lot that qtubuntu-sensors could do about that with the current API.

On the other hand, at this point platform-api does not really have a good option for error handling: It could require that IMPLEMENT_FUNCTION0 always returns a pointer and just return NULL on failure, so that ua_sensors_accelerometer_new() will then return NULL as expected if the sensor is not available. Or we add a new function to platform-api that checks if the backend is available, and if that returns false, qtubuntu-sensors will just avoid calling the ua_sensors_* bits entirely. Personally I favour the first option, it's safe and easier and avoids having to explicitly call this check function in clients.

After that, qtubuntu-sensors still needs to be fixed to check the return value for NULL as currently it just happily uses/calls this. It should instead set the QtSensor-typical error state.

Martin Pitt (pitti) wrote :

Note that before I can actually propose anything, platform-api first needs to become buildable in trusty again, which is blocked by landing these MPs:
  https://code.launchpad.net/~thomas-voss/platform-api/expose_accuracy_and_service_status_to_platform/+merge/203298
  https://code.launchpad.net/~thomas-voss/location-service/add_controller_and_service_configuration/+merge/199105

Changed in platform-api (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → High
status: New → In Progress
Martin Pitt (pitti) wrote :

I have fixes for platform-api and qtubuntu-sensors to deal with this properly now. qtubuntu-sensors has an MP, platform-api is blocked by the aforementioned MPs to make it buildable again in the first place in trusty. I'll send an MP once that happened.

Changed in qtubuntu-sensors (Ubuntu):
status: In Progress → Fix Committed
Martin Pitt (pitti) wrote :

Attaching the patch I tested this with which includes a fix for the float corruption (due to cmake bug 1274430) and requires building against the old dbus-cpp-dev (fished out of Launchpad). This is mostly to avoid losing the patch if some catastrophe happens to my Laptop, but review appreciated against that as well. I'll turn this into a proper MP once https://code.launchpad.net/~thomas-voss/platform-api/expose_accuracy_and_service_status_to_platform/+merge/203298 landed.

tags: added: patch
Martin Pitt (pitti) wrote :

location-api and platform-api have been fixed for the dbus-cpp change and are buildable again in trusty, so I created an MP for platform-api. As explained above, this is a prerequisite for the qtubuntu-sensors fix, and can safely go into trusty by itself.

Changed in platform-api (Ubuntu):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package platform-api - 0.20+14.04.20140211-0ubuntu1

---------------
platform-api (0.20+14.04.20140211-0ubuntu1) trusty; urgency=low

  [ Martin Pitt ]
  * Fix crash in ua_sensors_*_new() if there is no available backend.
    Return NULL instead. (LP: #1272294)
 -- Ubuntu daily release <email address hidden> Tue, 11 Feb 2014 00:09:33 +0000

Changed in platform-api (Ubuntu):
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

Now that platform-api has landed at last, I adjusted the qtubuntu-sensors MP. It's ready to land now.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qtubuntu-sensors - 0.6+14.04.20140213-0ubuntu1

---------------
qtubuntu-sensors (0.6+14.04.20140213-0ubuntu1) trusty; urgency=low

  [ Martin Pitt ]
  * Add integration tests for the QtSensor API → qtubuntu-sensors →
    platform-api (with simulated sensor backend).
  * Fix crash if there are no available sensors. (LP: #1272294)

  [ Albert Astals ]
  * Make it compile with Qt 5.2 (LP: #1271415). (LP: #1271415)
  * Q_ASSERT -> EXPECT_EQ Since sometimes Q_ASSERT can be compiled out
    and thus the test would fail. (LP: #1271886)
 -- Ubuntu daily release <email address hidden> Thu, 13 Feb 2014 01:44:53 +0000

Changed in qtubuntu-sensors (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers