Hi Bastien, On Sat, Dec 07, 2013, Bastien Nocera wrote: > On startup, if the SDP cache has been removed but the pairing > information is still present, we'd crash trying to access inside a > NULL record struct. > --- > profiles/input/device.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/profiles/input/device.c b/profiles/input/device.c > index 521aca8..62f6dbb 100644 > --- a/profiles/input/device.c > +++ b/profiles/input/device.c > @@ -811,6 +811,9 @@ static struct input_device *input_device_new(struct btd_service *service) > struct input_device *idev; > char name[HCI_MAX_NAME_LENGTH + 1]; > > + if (!rec) > + return NULL; > + > idev = g_new0(struct input_device, 1); > bacpy(&idev->src, btd_adapter_get_address(adapter)); > bacpy(&idev->dst, device_get_address(device)); I've applied your first patch, but I'd like to understand a bit better how you'd end up in this situation. Is this accomplishable through BlueZ APIs or only if one goes and messes with the storage directly? Either way, is this the best approach or should we consider still creating the input device but just ignore the bits that depend on the SDP record? Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
