Menu
▾
▴
Re: [Libusb-win32-devel] =?iso-8859-15?q?libusb-win32_weird_problem_w?= =?iso-8859-15?q?ith_0=2E1=2E12=2E0_on_XP_SP1=2C_but_works_with_0=2E1=2E10?= =?iso-8859-15?q?=2E1?=
|
From: Stephan M. <ste...@we...> - 2007-03-17 10:20:50
|
> [...] >=20 >=20 > Unfortunately, I discovered a problem. If I use libusb-win32 0.1.10.1, > everything works fine. If I use the version 0.1.10.2 (as it is called in= > the download section; the INF calls itself 0.1.12.0), I have a big > problem, which results in crashes sometimes, and in access violations in= > other times. The correct version is 0.1.12.0. I fixed it. >=20 >=20 > I think some notes on the architecture might be appropriate. The tool > (i.e., cbmctrl) uses a DLL (opencbm.dll), which itself uses another DLL > as plugin (in this case, opencbm-xu1541.dll). That DLL imported > libusb0.dll. >=20 > Note that opencbm-xu1541.dll is dynamically loaded by opencbm.dll by > using LoadLibrary(), GetProcAddress(), and FreeLibrary afterwards. It should make no difference whether the DLLs are "statically linked" or loaded at runtime. > [...] >=20 > Interestingly, the crashes almost always occur on program exit. To me, > it seems the heap gets corrupted, which results in the crash. >=20 > Note that my problems are with XP SP2. Another tester has the same > problem. Somehow weird, another tester using Windows 2000 reports no > problems at all! >=20 >=20 > I started some debugging and found something. At least, I could > make go away that crash. Now, all commands which only use "reading" from= > the USB work - that is, calls to =5Fusb=5Fio=5Fsync() where "requesttype & > USB=5FENDPOINT=5FIN" is true. >=20 > What did I change=3F I looked into the sources file for libusb-win32 and > found out that it uses MSVCRT.DLL as run-time library (instead of a > statically linked run-time library). >=20 > I changed opencbm.dll and opencbm-xu1541.dll to use the same DLL, and > these crashes are gone now. >=20 > Note that I am no expert on DLLs. Is this the expected behaviour=3F Should= > it be the same=3F Why should "my" DLLs use the same run-time library as > you=3F I'm no DLL expert either but it's usually good practice to link all system= libraries such as msvcrt.dll dynamically because: * this saves memory and disk space * speeds up application startup * ensures that all components of an application use exactly the same=20 library/DLL versions >=20 > Unfortunately, the other problem (with access violations) remains for > the commands where =5Fusb=5Fio=5Fsync() "requesttype & USB=5FENDPOINT=5FIN" is > false. >=20 > I debugged it as follows in WinDBG: I compiled libusb0.dll myself (using= > make=5Fdll in the ddk=5Fmake/ directory, and utilizing the LIB, DLL and PDB > I got). >=20 > Have a look at libusb/src/windows.c > (http://libusb-win32.svn.sourceforge.net/viewvc/libusb-win32/trunk/libus= b/src/windows.c=3Frevision=3D148&view=3Dmarkup), > function usb=5Fcontrol=5Fmsg() (lines 659ff): >=20 > Everything works fine as long as the if() in line 770 (if(!(requesttype > & USB=5FENDPOINT=5FIN))) is not true. Line 783ff (=5Fusb=5Fio=5Fsync()) succeeds, > and everytings works. >=20 > This is the reason why the access violation depends upon the requesttype= > & USB=5FENDPOINT=5FIN value. >=20 > If the if() in line 770 is true, lines 771-781 malloc()s a new memory > area for the request req. req is a local variable, which is copied over > the newly allocated memory. Additionally, the output data is copied > after that request. >=20 > I can see that the malloc() succeeds, and the copying works as expected > (at least as I expect it), too. Nevertheless, the call in line 783 > (=5Fusb=5Fio=5Fsync()) fails now! >=20 > Have a look into =5Fusb=5Fio=5Fsync(), line 1170 of windows.c: It fails with > error code 0xc0000005 (access violation). I can clearly see in the > debugger that the memory referenced by the pointer out is valid, as is > the data referenced by the pointer in. I can follow the OS function > DeviceIoControl() until the SYSENTER. All pointers up to there are valid= > and correctly used. Doing the next step, I get the access violation. Have you verified that all parameters passed to DeviceIoControl() are valid and correct=3F Please check the 'ol' parameter. Is it corrently initia= lized and is 'ol.hEvent' valid=3F >=20 > To be honest, I don't have a clue what is really going on, and how this > can be solved. >=20 > Unfortunately, I cannot debug this better, as >=20 > 1. I don't have a second XP based machine to debug the call into > kernel-mode, too, and >=20 > 2. somehow, I have not managed to get libusb-win32 claim the device > inside of VMWare (which would allow me to debug the kernel calls, > too). Where does the crash and the access violation occur=3F In user-space or in kernel space=3F Do you get a BSOD=3F If the access violation occurs in user-space then debugging in kernel-spac= e won't make much sense. >=20 >=20 > I am not sure if this is somehow related to restrictions of a DLL. I > remembered that malloc() and printf() are problematic in a DLL. I came > up with the following article in MSDN: >=20 > http://support.microsoft.com/=3Fscid=3Dkb%3Ben-us%3B94248&x=3D15&y=3D15 >=20 > I thought I might have some problem with the initialization of the CRT. > For this, I changed all DLL entry points in my code to DllEntry(); > anyway, the problems did not go away. Thanks for the link. I changed the DLL's entry point to =5FDllMainCRTStartup= @12=20 as recommended by the article. A new version is attached. Please give it a= try. >=20 >=20 > Any hints and ideas are welcome. >=20 > Regards, > Spiro. >=20 > --=20 > Spiro R. Trikaliotis http://opencbm.sf.net/= > http://www.trikaliotis.net/ http://www.viceteam.org/= >=20 > ------------------------------------------------------------------------= - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share = your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php=3Fpage=3Djoin.php&p=3Dsourceforge&CID=3DDEVDE= V > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Libusb-win32-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel >=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Viren-Scan f=FCr Ihren PC! Jetzt f=FCr jeden. Sofort, online und kostenlos. Gleich testen! http://www.pc-sicherheit.web.de/freescan/=3Fmc=3D022222 |
