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