On 2013.01.29 16:45, Mohamed HAMZAOUI wrote: > I updated the libusbx but i think the modifications doesn't help you > because the crash is before this log call
Yeah, I've been wondering about that, but still I want to see what the error code is, so that at the very least we can improve our handling of errors. Also, judging from the log below, you do seem to get a different error code than from your last run. That "overlapped I/O not in a signaled state" message may still give us at least some additional clues about what's going on, so I wouldn't be too fast about dismissing it altogether, especially as these "crash occurs after <large_number> of transfers" or "crash occurs after <large time interval>" are usually very difficult to investigate if we can't reproduce them on our end. > Yes I'am linking with linking pthread-win32 library for portability > consideration. OK. > Now I use libusbx library static in debug mode (i just have changed > /MTd to /MDd in compiling parameter). I guess that means you're not using cygwin but MSVC. > 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. Judging from your last message, I would think the crash is likely to occur due to a bad pointer ref. Not sure about the address for the dev_handle being wrong, when the addresses for length and callback seem to follow as expected. I'd rather see the dev_handle->dev being a bad reference, and the cause of the crash. Do you have any means of finding out what dev_handle->dev is at the time of the crash? The struct definitions for libusb_device_handle and libusb_device can be seen here [1], and I guess if you can peek into where dev is supposed to point, the values held by refcnt, bus_number and port_number should tell us whether that looks like an actual libusb device, or if it's just random/corrupted memory. > 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. Does that mean that you were also getting those "Overlapped I/O event is not in a signaled state" in your previous test, and that this is a different message from the errocode 317 one. I think that if these Overlapped errors are what happen first, this is probably what we want to have a closer look at. I'll see if I can figure what could cause such a message. > libusbx: warning [usbi_poll] invalid fd Also interesting. Any warning that occurs before an error/crash is not something we want to ignore. Regards, /Pete [1] https://github.com/libusbx/libusbx/blob/master/libusb/libusbi.h#L265 ------------------------------------------------------------------------------ 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
