Please do not take into account this :
libusb_cancel_transfer(transfer->xfer); /* the callback do the free */
Regards,
Mohamed
On Mon, Jan 28, 2013 at 10:57 AM, Mohamed HAMZAOUI <requin...@gmail.com> wrote:
> 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
