On 2012.08.02 12:04, sebasti...@gmx-topmail.de wrote: > For the first backtrace: > (gdb) print &ctx->flying_transfers > $3 = (struct list_head *) 0x9088ed8 > > For the second backtrace: > (gdb) print &ctx->flying_transfers > $3 = (struct list_head *) 0x8b63ed8
Thanks. This confirms that our list has a single element at 0xb660046c in the case of the first trace. I don't think we crash on the first 'cur' variable being computed in list_for_each_entry(), as ctx->flying_transfers.next is a proper address, and should produce a 'cur' with an address of 0xb6600468 then. I guess I'd be curious to see a short memory dump (16 bytes should do) of 0xb6600468 now (or 0x8b64a08 for the second backtrace), to confirm that our usbi_transfer struct for that unique list element is not set properly. 'x 0xb6600468' should achieve just that. Or if you can cast that address as a struct usbi_transfer, you may be able to get a more explicit dump of the data. I think 'print (struct usbi_transfer)0xb6600468' should do but if that doesn't work, the hex dump should do just fine. What I'm trying to confirm is that the "&cur->list != (&ctx->flying_transfers)" test, that is meant to end the list_for_each_entry() loop after processing the first and unique entry, is never reached due to an improper pointer. Once we confirm that, we can try to locate what might be causing that pointer to be wrong 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
