On Thu, Aug 2, 2012 at 9:30 AM, Orin Eman <orin.e...@gmail.com> wrote:
> I've seen the list get screwed up by trying to reissue a transfer before
> getting the callback. The list got a circular segment in that case.
> Perhaps something like cancelling a transfer followed by freeing it before
> getting the callback causes this?
>
> I made a couple of changes to trap this - I'll see if I still have the
> code when I get to work.
>
In my case, I was trapping the list getting a circular segment, so I made
the following changes:
static inline void list_del(struct list_head *entry)
{
entry->next->prev = entry->prev;
entry->prev->next = entry->next;
entry->next = entry->prev = NULL;
}
static inline void list_verify(struct list_head *head)
{
struct list_head *next;
for ( next = head->next; next != head; next = next->next )
{
if ( next->next == next && next != head )
{
DebugBreak();
}
}
}
And scattered calls to list_verify() after each operation done on the
flying transfer list.
Setting next and prev to NULL in list_del() caused a crash in
usbi_cond_destroy() in threads_windows.c (next was used after calling
list_del). Using list_for_each_entry_safe fixed it and cleaned up the code.
int usbi_cond_destroy(usbi_cond_t *cond) {
// This assumes no one is using this anymore. The check MAY NOT BE
safe.
struct usbi_cond_perthread *pos, *next_pos = NULL;
if(!cond) return ((errno=EINVAL));
if(!list_empty(&cond->waiters)) return ((errno=EBUSY )); // (!see
above!)
list_for_each_entry_safe(pos, next_pos, &cond->not_waiting, list,
struct usbi_cond_perthread) {
CloseHandle(pos->event);
list_del(&pos->list);
free(pos);
}
return 0;
}
When I was looking at my problem, all the use of the flying transfer list
looked properly protected, so my guess is still that the problem is outside
of libusb and a transfer is being freed while still on the list.
Orin.
> On Thu, Aug 2, 2012 at 6:13 AM, Pete Batard <p...@akeo.ie> wrote:
>
>> On 2012.08.02 13:28, sebasti...@gmx-topmail.de wrote:
>> > (gdb) print ((struct usbi_transfer*)0xb6600468)->list
>> > $4 = {prev = 0x0, next = 0x0}
>>
>> This confirms that our list is screwed up and since we don't check for
>> the next/prev validity, we end up with a NULL dereference (actually
>> NULL-4), hence the crash.
>>
>> Now we have to find out why one of list_add, list_add_tail, list_del
>> results in prev/next being NULL...
>>
>> Regards,
>>
>> /Pete
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> libusbx-devel mailing list
>> libusbx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
>>
>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
