This is the mail archive of the
mailing list for the Cygwin project.
Re: BLODA detection (was Re: Debugging help for fork failure: resource temporarily unavailable)
- From: Jon TURNEY <jon dot turney at dronecode dot org dot uk>
- To: cygwin at cygwin dot com
- Date: Mon, 04 Apr 2011 14:00:44 +0100
- Subject: Re: BLODA detection (was Re: Debugging help for fork failure: resource temporarily unavailable)
- References: <firstname.lastname@example.org> <4D811176.email@example.com>
On 16/03/2011 19:37, Ryan Johnson wrote:
> On 2:59 PM, Henry S. Thompson wrote:
>> Ryan Johnson writes:
>>> BTW, I found a good way to identify, if not fix, BLODA: given an app
>>> which loads no libraries at runtime -- such as 'ls' -- any dlls
>>> mentioned in /proc/$$/maps which cygcheck does not mention are
>>> probably dodgy. In my case, Windows Live (which I didn't think was
>>> even installed on my machine) has injected a WLIDNSP.DLL ("Microsoft
>>> Windows Live ID Namespace Provider") in all my processes.
>> This would be super-cool if true, but it doesn't work for me. . .
>> If I try, I find
>> in /proc/[ls procid]/maps but not in cygcheck output, but none of
>> those are BLODA, right?
>> [Note also that maps shows many things in syswow64 which cygcheck
>> shows in system32, but presumably that's because cygcheck itself is a
>> 32-bit app, is it?]
> $ join -i -v 1 <(cat /proc/$$/maps | sed 's;^.*/;;' | sort -f) <(cygcheck
> $(cat /proc/$$/winexename) | sed 's;^.*\\;;' | sort -f)
> The above shows all dlls loaded by the process which are not linked in at
> compile time. Does bash really load so many dynamic libraries, or is cygcheck
> missing things?
system DLLs dyamically load other DLLs, both for extensibility and for
performance (delay-loading), so this list doesn't really tell you anything
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple