Comment 8 for bug 1272294

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.