I have an important inforation,
I added a hanling event instruction on sender thread just after
sending, so, we have one thread for handling and another thread for
sending and handling an event after sending
and i protect the two handling call with libusb_lock/unlock_event
function like that :
/************handler events thread**********/
static void *event_handler_thread(void *args)
{
struct dtlib *lib = (struct dtlib *) args;
int ret = 0;
struct timeval tv = {0,0};/*I CHANGE THIS VALUE FROM 1,0 to 0,0*/
while (1)
{
pthread_mutex_lock(&lib->run_mutex);
if (!lib->run)
{
break;
}
pthread_mutex_unlock(&lib->run_mutex);
/* my libusb_close will kick this blocking function, so it is safe to
call it here
this way */
libusb_lock_events(lib->ctx);
ret = libusb_handle_events_timeout_completed(lib->ctx, &tv, NULL);
libusb_unlock_events(lib->ctx);
if (ret)
{
printf("event_handler_thread : libusb_handle_events ret %d \n",ret);
}
}
pthread_mutex_unlock(&lib->run_mutex);
printf("event_handler_thread : Good bye\n");
return NULL;
}
/***********sender thread will execute this function *************/
static int submit_transfer(struct usb_device *dev, struct message
*msg, unsigned int lenUsbFrame)
{
struct transfer *transfer;
int status;
int ret;
transfer = transfer_pool_alloc(dev->pool); //here it take a transfer
from free list if existe else it return NULL
if (transfer == NULL)
return -2;
memcpy(transfer->buffer, msg, lenUsbFrame);
// we update the lentgth of USB frame
transfer->xfer->length = lenUsbFrame;
status = libusb_submit_transfer(transfer->xfer);
if (status != 0) {
transfer_pool_free(transfer);
fprintf(stderr, "libusb_submit_transfer fail: %d\n", status);
return -1;
}
libusb_lock_events(dev->ctx);
ret = libusb_handle_events_timeout_completed(dev->ctx, &tv, NULL);
libusb_unlock_events(dev->ctx);
if (ret)
{
#ifdef DRIVER_LOG
printf("Problem in libusb_handle_events_timeout_completed at
submit_transfer : %d", ret);
#endif
}
return 1;
}
/*********************/
The result is that : all the -1 handling event errors have disappeared !
Does the number of handling event call should be equal or great the
number of transfer submitting given that the handler thread execute
the callback and then spent more time on executing them ?
The other remark is THAT THE CRASH PERSIST :'(
Any Idea
Regards,
Mohamed
On Wed, Jan 30, 2013 at 9:26 PM, Mohamed HAMZAOUI <requin...@gmail.com> wrote:
> 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
