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!
Furthermore, if you receive UHID_FEATURE, the kernel blocks until you
send the answer as UHID_FEATURE_ANSWER. I really recommend dropping
this line:
bt_uhid_register(hogdev->uhid, UHID_FEATURE, forward_report, hogdev);
Add it again once you implemented UHID_FEATURE properly. Currently,
it's totally broken.
Thanks
David
--
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
