On 2013.01.30 20:43, Mohamed HAMZAOUI wrote: > 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 ?
I'm not sure I understand your question, but I don't think we should try to be drawing conclusions from trying to balance the number handling events with the number of transfers. As a general rule, you should not make assumptions as to the number of "transactions" a library is meant to handle in its event handler. For instance a library could have dedicated events for internal processing, that have nothing to do with transactions, or handle multiple transactions when processing a single event. We could of course try to dig up what the story is in the libusbx case, but I don't think it will help that much. The thing is: we have a crash, which appears to be due to the application/library trying to access a memory location that doesn't contain the expected data. If we can find what this data is, and whether it was prematurely freed (and when), or just not properly initialized, we'll probably have found the reason for the bug. So as I asked previously, do you have any means of finding out what dev_handle->dev is at the time of the crash, since it seems to be the location that causes it, and whether the data that dev points to looks to what one would expect for the device you are trying to access (it should contain a bus, port and device address that you should be able to cross reference from running xusb against your device, or by running your enumeration in debug mode). Depending on whether it does or it doesn't, we can try to figure out what the next step will be in identifying the cause of the crash. Regards, /Pete ------------------------------------------------------------------------------ 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
