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

Reply via email to