Hi David,
On Thu, Jul 24, 2014 at 6:12 PM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote:
> Hi
>
> On Thu, Jul 24, 2014 at 12:08 PM, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote:
>> Hi Murat,
>>
>> On Thu, Jul 24, 2014, Murat Kilivan wrote:
>>> ==10991== Process terminating with default action of signal 5 (SIGTRAP)
>>> ==10991== at 0x40A340A: g_logv (in /lib/i386-linux-gnu/libglib-2.0.so.0.4000.0)
>>> ==10991== by 0x40A3522: g_log (in /lib/i386-linux-gnu/libglib-2.0.so.0.4000.0)
>>> ==10991== by 0x40A1C1D: g_malloc (in /lib/i386-linux-gnu/libglib-2.0.so.0.4000.0)
>>> ==10991== by 0x40B9E75: g_memdup (in /lib/i386-linux-gnu/libglib-2.0.so.0.4000.0)
>>> ==10991== by 0x80781C5: gatt_write_char (gatt.c:900)
>>> ==10991== by 0x8072A7B: forward_report (hog.c:368)
>>> ==10991== by 0x80A5B0D: queue_foreach (queue.c:206)
>>> ==10991== by 0x807208E: uhid_read_handler (uhid.c:98)
>>> ==10991== by 0x80A53F2: read_callback (io-glib.c:168)
>>> ==10991== by 0x40E1E04: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.4000.0)
>>> ==10991== by 0x409C0A6: g_main_context_dispatch (in /lib/i386-linux-gnu/libglib-2.0.so.0.4000.0)
>>> ==10991== by 0x409C467: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.4000.0)
>>> ==10991== Invalid free() / delete / delete[] / realloc()
>>> ==10991== at 0x402B3D8: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
>>> ==10991== by 0x4304F54: __libc_freeres (in /lib/i386-linux-gnu/libc-2.19.so)
>>> ==10991== by 0x4024526: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-x86-linux.so)
>>> ==10991== by 0x40E4F6D: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.4000.0)
>>> ==10991== Address 0xffffffff is not stack'd, malloc'd or (recently) free'd
>>
>> This helps a lot. Thanks. I'd bet the following code from forward_report() is
>> responsible:
>>
>> if (hogdev->has_report_id) {
>> data = ev->u.output.data + 1;
>> size = ev->u.output.size - 1;
>> } else {
>> data = ev->u.output.data;
>> size = ev->u.output.size;
>> }
>
> The kernel bails out if size==0, so this never happens. The bt_uhid_*
> helpers are fine, however, hog.c forward_report() is totally broken.
> You use:
>
> bt_uhid_register(hogdev->uhid, UHID_OUTPUT, forward_report, hogdev);
> bt_uhid_register(hogdev->uhid, UHID_FEATURE, forward_report, hogdev);
>
> Therefore, you register *THE SAME* handler for UHID_OUTPUT *AND*
> UHID_FEATURE. However, in forward_report() you access ev->u.output,
> but this is only valid for UHID_OUTPUT. If you get a UHID_FEATURE
> report you must never access anything but ev->u.feature!
Does the ev->u.features structure matches HID protocol, can I send as
it is or do I need to reformat it?
> Furthermore, if you receive UHID_FEATURE, the kernel blocks until you
> send the answer as UHID_FEATURE_ANSWER.
So if I got this right in addition to send the request we should
process the response as UHID_FEATURE_ANSWER otherwise it will block
other events?
--
Luiz Augusto von Dentz
--
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
