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: Ryan Johnson <ryanjohn at ece dot cmu dot edu>
- To: "Henry S. Thompson" <ht at inf dot ed dot ac dot uk>
- Cc: cygwin at cygwin dot com
- Date: Wed, 16 Mar 2011 15:37:26 -0400
- Subject: Re: BLODA detection (was Re: Debugging help for fork failure: resource temporarily unavailable)
- References: <firstname.lastname@example.org>
On 2:59 PM, Henry S. Thompson wrote:
Ryan Johnson writes:Interesting...
This would be super-cool if true, but it doesn't work for me. . .
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.
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?
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple