On 04/06/2009 11:09, Charles Wilson wrote:
Well, you can never be SURE. I'd be surprised tho. I use AVG 8.5, which doesn't cause any problems on my cygwin-1.5 installation under Vista, nor on XP. Nobody has ever reported it as a BLODA before, AFAICT. It does do on-access scanning, which means it hooks in to the file-access machinery just like other BLODAs (although I've turned that off for my cygwin-1.7 and -1.5 trees, not that doing THAT would make any difference to a true BLODA). What I can't figure out is, if AVG were at fault, why it would always "attack" my cygwin-1.7 tree, but never interfere with my cygwin-1.5 tree on the same disk. I can even run automake from a cygwin-1.7 shell and watch it die, and immediately run automake from a cygwin-1.5 shell in the same directory and it succeeds...so if it's a BLODA, it's got a jones for cygwin-1.7.
I'm having similar problems with Avast 4.8 Home Edition on Windows 7 RC x64 with cygwin-1.7. I never had a problem with this A/V on XP with 1.5 or 1.7. This continues even after rebaseall and peflagsall. I have yet to try removing Avast.
In any event, since the remap problem happens in violation of everything MS says ASLR is supposed to do, I blame Vista (or maybe possible-BLODA-interfering-with-ASLR directly, not with cygwin itself). I can inspect the new (randomized) base addresses of the ASLR-marked DLLs after each reboot by looking at running processes using the sysinternals process viewer. They are (a) random and (b) non-overlapping. But when the "*** failed to remap" occurs, I can inspect the hung process and sure enough, foo.dll is loaded in some strange place in memory that is NOT where ASLR promised to put it (and there is no obvious conflicting DLL loaded where foo.dll was supposed to go).
Leave it to MS to mess us up again... Yaakov -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
