On Wed, Jan 30, 2013 at 6:33 AM, Xiaofan Chen <xiaof...@gmail.com> wrote:
> On Wed, Jan 30, 2013 at 12:45 AM, Mohamed HAMZAOUI <requin...@gmail.com> 
> wrote:
>> Now I use libusbx library static in debug mode (i just have changed
>> /MTd to /MDd in compiling parameter).
>>
>> more information about the bug : there is a corruption in memory
>> because the dev handle address are wrong 0x4f8 and this is the cause
>> of crash. the io_result value's 0x3e4 !
>>
>> ************ the debug state of transfer parameter in
>> windows_transfer_callback at crash************
>> - transfer 0x024aec64 {dev_handle=0x000004f8 flags=0x00 endpoint=0x00
>> ...} libusb_transfer *
>> + dev_handle 0x000004f8 {lock=??? claimed_interfaces=??? list={...}
>> ...} libusb_device_handle *
>> flags 0x00 unsigned char
>> endpoint 0x00 unsigned char
>> type 0x00 unsigned char
>> timeout 0x00000000 unsigned int
>> status LIBUSB_TRANSFER_COMPLETED libusb_transfer_status
>> length 0x000004fc int
>> actual_length 0x00000001 int
>> callback 0x00000500 void (libusb_transfer *)*
>> user_data 0x024aec80 void *
>> + buffer 0x024aec80 "€ìJ €ìJ  H2  H2 ýýýý" unsigned char *
>> num_iso_packets 0x0b324890 int
>> iso_packet_desc 0x024aec8c {length=0x0b324890 actual_length=0xfdfdfdfd
>> status=LIBUSB_TRANSFER_COMPLETED } libusb_iso_packet_descriptor [0]
>> *****************************************************************************************************************
>
> Hmm, why are there isochronous related thingy here?

this is just the MSVC debug information at crash of transfer variable.
There is struct libusb_iso_packet_descriptor member in this struct,
but maybe the address affected to this member is caused by the memory
corruption !

>
>> there are many -1 error when handling transfer before the crash and
>
> Could this be related to noise or things like that? What if you change
> to use another PC and use a cleaner power supply?
I test this issue on all PCs (Dell) of my team (3 with Win7 and 3 with
WinXP) and we have the same crash !
>
> What happen to your device after the crash? Does the device
> go to an unstable state and only a reset will get it back? If the

Until crash, device embedded software are in stable state and it works
normally (analysed with JTAG) and when I restart application, the
device start normally.

> device firmware hangs due to noise, it could cause transfer to
> fail. The crash may due to some race condition in your pthread-win32
> codes then.
I don't see how race condition in my program can cause problem ?

Regards,
Mohamed

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Reply via email to