Another remark : I found the same problem in an old libusb ticket
http://www.libusb.org/ticket/140
maybe the memory corruption is caused by pthread-win32 in a stress context ?
ragards,
Mohamed
On Tue, Jan 29, 2013 at 5:45 PM, Mohamed HAMZAOUI <requin...@gmail.com> wrote:
> Hi Pete,
>
> Thank you for your response.
>
> I updated the libusbx but i think the modifications doesn't help you
> because the crash is before this log call
> Yes I'am linking with linking pthread-win32 library for portability
> consideration.
> 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]
> *****************************************************************************************************************
>
> there are many -1 error when handling transfer before the crash and
> the last part of log's :
> libusbx: error [windows_transfer_callback] detected I/O error 996:
> [996] Overlapped I/O event is not in a signaled state.
> OUT ERROR 1 AT COMPLETION_EP_OUT_CB <<------- my log
> libusbx: warning [usbi_poll] invalid fd
> libusbx: error [handle_events] poll failed -1 err=9
>
> event_handler_thread : libusb_handle_events ret -1
>>>>>crash :'( <<<<
>
> Regards,
> Mohamed
>
> On Tue, Jan 29, 2013 at 12:58 AM, Pete Batard <p...@akeo.ie> wrote:
>> Hi Mohamed,
>>
>> On 2013.01.28 09:57, Mohamed HAMZAOUI wrote:
>>> I return for you for a crash problem in my soft.
>>> For remember, I'm now developping a software based on libusbx to send
>>> and receive with my CAN-USB gateway card.
>>> In my program i have a start a thread to handle event with this code :
>>> static void *event_handler_thread(void *args)
>>> {
>>> struct dtlib *lib = (struct dtlib *) args;
>>> int ret = 0;
>>> struct timeval tv = {1,0};
>>> /*SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_HIGHEST);*/
>>> while (1)
>>> {
>>> pthread_mutex_lock(&lib->run_mutex);
>>> if (!lib->run)
>>> {
>>> break;
>>> }
>>> pthread_mutex_unlock(&lib->run_mutex);
>>
>> So you're linking your application with the pthread-win32 library, right?
>> Or are you using cygwin by any chance?
>>
>> Either way, I don't think mixing pthread-win32 with Windows native
>> threading should cause much of an issue for locks, especially as your
>> error doesn't seem be related to a deadlock, but it may be worth noting
>> that, if you're not developing on cygwin, you're using 2 different
>> threading mechanisms in your application.
>>
>>> When i try to send with maximum 60 transfer concurrently, it work for
>>> 400s (on average) after sending more than 420000 USB frame to the
>>> device and it crash here :
>>> (windows_usb.c)
>>> static void windows_transfer_callback(struct usbi_transfer *itransfer,
>>> uint32_t io_result, uint32_t io_size)
>>> {
>>> struct libusb_transfer *transfer =
>>> USBI_TRANSFER_TO_LIBUSB_TRANSFER(itransfer);
>>> -------->>> struct windows_device_priv *priv =
>>> _device_priv(transfer->dev_handle->dev); <<<----------- Crash
>>>
>>> and the last part log is :
>>> libusbx: error [windows_transfer_callback] detected I/O error: Windows
>>> error code 317 (FormatMessage error code 87)
>>> libusbx: warning [usbi_poll] invalid fd
>>> libusbx: error [handle_events] poll failed -1 err=9
>>
>> Unfortunately, the error message is not useful in this case. I tried to
>> get a system translation of error 317 and got the same output.
>>
>> According to winerror.h, code 317 is: "The system cannot find message
>> text for message number 0x%1 in the message file for %2.", which makes
>> it even more puzzling for something supposed to be returned on I/O error.
>>
>> If running in debug mode, you should have a ""handling I/O completion
>> with errcode ###" before that error, that should give more clues as to
>> what is going on.
>>
>> As far as I recall, the way I coded windows_transfer_callback() [1],
>> which is where the problem seems to manifest itself first, was with a
>> switch to handle all the error codes that I personally experienced
>> during development, and a default case for what I had not seen. This
>> default switch is where you appear to end up, so it looks like you ran
>> into a situation we haven't been able to simulate so far, and where our
>> default handling might not work that well. See the io_result you have
>> when entering windows_transfer_callback() would be great help, as it
>> should be a standard Windows error code that could provide more
>> information as to what the actual issue is (unless it's really code 317,
>> in which case I'm not sure what the story is).
>>
>> The io_result value is always displayed when running libusbx with the
>> debug log, but in case you cannot reproduce the issue in debug mode, I
>> have just pushed a patch that will display the io_result value, in the
>> error message for the default case, even if not running in debug mode.
>>
>> Can you please try recompiling your app using the latest libusbx from
>> git (see [2]) so that we can find out what the original I/O error code is?
>>
>> Regards,
>>
>> /Pete
>>
>> [1]
>> https://github.com/libusbx/libusbx/blob/master/libusb/os/windows_usb.c#L2029
>> [2] https://github.com/libusbx/libusbx/wiki#wiki-Accessing_the_Source
>>
>> ------------------------------------------------------------------------------
>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>> MVPs and experts. ON SALE this month only -- learn more at:
>> http://p.sf.net/sfu/learnnow-d2d
>> _______________________________________________
>> libusbx-devel mailing list
>> libusbx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/libusbx-devel
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
