Hi,
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);
/* my libusb_close will kick this blocking function, so it is safe to
call it here
this way */
ret = libusb_handle_events_timeout_completed(lib->ctx, &tv, NULL);
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;
}
and I send can frame from another thread (using a pre-allocated pool
of transfer in 2 double linked list free_list and used_list) like this
:
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) {
libusb_cancel_transfer(transfer->xfer); /* the callback do the free */
transfer_pool_free(transfer);
fprintf(stderr, "libusb_submit_transfer fail: %d\n", status);
return -1;
}
return 1;
}
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
Can you help me on this please.
Regards,
Mohamed
On Fri, Dec 14, 2012 at 12:15 AM, Pete Batard <p...@akeo.ie> wrote:
> Mohamed,
>
> Please bear in mind that, Peter Stuge's conflicting statement with
> regards to the answer previously given by Xiaofan, and earlier myself,
> is from someone who is (was) a simple subscriber of libusbx, as well as
> the sole lead of a competing project, and is therefore not an official
> voice of the libusbx project, like Xioafan or myself.
> As such he should never have replied with a "Yes" statement, and this
> unfortunately renders things confusing for users like yourself, as it
> require us to waste time trying to clean up the mess.
>
> As I tried to explain previously, this does not qualify as a bug.
> It is a conscious decision to limit libusbx with regards to a behaviour
> that we estimated at the time, and still estimate now, is most likely
> going to be indicative of a problem with the libusbx-based software
> being designed, and therefore shouldn't need to warrant additional
> development until we have a real-life case for it.
> Whenever one designs software (an ever-prodigal race against time), the
> decision to catter for a very unlikely case is usually trumped by the
> need to press on with other matters, and this is exactly what occurred
> there.
> Now, it is possible that with USB 3.0, maybe some people will feel that
> running 256 CONCURRENT transfers on Windows is fair game and that
> libusbx should allow it, in which case I don't see much of a problem
> raising the table boundary, but I'd still like to see a proper real-life
> scenario for having an unbounded number of fds, and I'm afraid I still
> don't see your usage qualifying as one.
>
> But let's say we were to remove that limit altogether and grow that
> table dynamically. Now what?
>
> You indicated that in about 15 seconds, the 256 fds currently provided
> by libusbx are going to be allocated. So what happens if you let your
> software run for weeks on end? At the very least, you'll find that
> libusbx "leaks" about 2KB/minute and that as lookups become more and
> more time consuming (especially if we "grow" that table), so you'll get
> data drops and other undesirable behaviour.
>
> Now, if you say that the need for 256+n fds is only during an initial
> burst, and that the transfers are going to decrease after that, so that
> previous transfers can be processed, then you should be able to provide
> us with an estimate of how many extra fds (n) you would need during this
> initial burst period (knowing that the more fds you have, the more
> sluggishly libusbx will behave). Do you have such an estimate?
>
> If not, then I would advise you, as Tim and Xiaofan have already pointed
> out, to try to determine what the limits of your software are going to
> be as, even if libusbx doesn't try to set limits, if you have no idea
> how much resources your application may consume, you are bound to run
> out of them eventually and will have to design/fix your software
> accordingly.
>
> If you provide us with an estimate of how much concurrent transfers
> your application actually requires, then should be in a better position
> to devise what we think will be the best approach to satisfy everybody.
> But UNLESS you are able to get such an estimate, you need to understand
> that asking for the underlying software to be limitless will pointless.
> If you find out that your software actually requires a limitless number
> of fds when it runs, you will have to fix or redesign it one way or
> another, and you should be mindful that all libusbx did here is tell
> you, ahead of time, that you will have to fix/redesign it.
>
> Finally, you also want to be mindful that something that works fine on
> Linux, but that, given your timings, is probably very close to the
> maximum rate such a system can handle, may end up not working on Windows
> even with the same hardware, as there might be more overhead there... Or
> maybe you just didn't let the software run long enough to realize it was
> allocating more and more resources?
>
>
> In other news, please be advised that Peter Stuge has now been banned
> from libusbx-devel.
> If you have an issue with that [remember that this is something I
> repeatedly notified this list may happen], I'll be happy to explain, for
> one last time, why his contributions to this list have been much more
> undermining than helpful, and why I am confident that not having to deal
> with Peter's scare tactics, contradicting opinions or desire to tag
> whatever he doesn't like from libusbx as a bug, will ensure that this
> list is better off and friendlier to new users.
> Also remember that you have plenty of opportunity to interact with Peter
> on the libusb-devel [1] or other mailing lists, so if you want to jump
> on the high horse of "unilateral censorship", please be my guest.
>
> Regards,
>
> /Pete
>
> [1] https://lists.sourceforge.net/lists/listinfo/libusb-devel
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> 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
