On 2:59 PM, Ryan Johnson wrote:
I wrote a very simple program whose main() prints out the contents of
/proc/self/maps, forks, calls foo() and bar(), and finally (if the
parent) calls wait().
The trick is, foo() and bar() reside in cygfoo.dll and cygbar.dll
respectively, which I compiled to
On 2:59 PM, Jon TURNEY wrote:
On 15/03/2011 13:53, Ryan Johnson wrote:
All of this assumes Windows is consistent in choosing locations when conflicts
It's assumed that CreateProcess() produces the same layout, yes.
This assumption is due to what?
- Documented Windows feature?
- An observation
On 2:59 PM, Ryan Johnson wrote:
On 2:59 PM, Jon TURNEY wrote:
I look forward to reading your patches :-)
I think it's still rather premature to be cooking up a patch,
unfortunately -- I'm not convinced I know yet where the real problem
lies. Without some data to back up my speculation (which
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
On 15/03/2011 13:53, Ryan Johnson wrote:
All of this assumes Windows is consistent in choosing locations when conflicts
It's assumed that CreateProcess() produces the same layout, yes.
are involved. IOW, consider the case that B depends on A, with A and B both
conflicting with a later-loaded
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
On 2:59 PM, Jon TURNEY wrote:
On 09/03/2011 17:04, Ryan Johnson wrote
BTW, while looking at the code I noticed a potential source of remap problems:
if B depends on A, and we remap A first, then only A's location will be
checked carefully; B will be pulled in wherever it happens to end up when
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
On 07/03/2011 15:10, Ryan Johnson wrote:
Actually, a follow-up question: what is the difference between the fork(e.g.
resource unavailable) failures vs. the errors about 'failed to remap dll...'
? Looking at the code in dll_init.cc, if failure to remap a dll were really
the source of fork
On Mar 5 17:15, Ryan Johnson wrote:
Hi all,
I'm hitting the oh-so-delightful fork failures when trying to
compile a cross-compiler toolchain, which is a pain because one fork
failure makes crosstool-ng start over. I've rebased, I've been over
the BLODA (Windows Defender slipped in even
On Wed, Mar 09, 2011 at 11:22:57AM +0100, Corinna Vinschen wrote:
Just an idea. Somebody still would have to do it(*).
I've been musing about some ways to make dll handling more robust.
Maybe I'll poke at it for 1.7.10.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On 2:59 PM, Corinna Vinschen wrote:
On Mar 5 17:15, Ryan Johnson wrote:
Might it be possible to do an LD_PRELOAD of some sort which hooks
into fork() at the critical moment and prints the differences
between /proc/$parent/maps and /proc/$child/maps? The code doesn't
even need to be efficient;
On 2:59 PM, Ryan Johnson wrote:
I'm hitting the oh-so-delightful fork failures when trying to compile
a cross-compiler toolchain, which is a pain because one fork failure
makes crosstool-ng start over. I've rebased, I've been over the BLODA
(Windows Defender slipped in even after I rejected
On 2:59 PM, Ryan Johnson wrote:
I'm hitting the oh-so-delightful fork failures when trying
to compile a cross-compiler toolchain, which is a pain
because one fork failure makes crosstool-ng start over. I've
rebased, I've been over the BLODA (Windows Defender slipped
in even after I rejected
Hi all,
I'm hitting the oh-so-delightful fork failures when trying to compile a
cross-compiler toolchain, which is a pain because one fork failure makes
crosstool-ng start over. I've rebased, I've been over the BLODA (Windows
Defender slipped in even after I rejected the download), and while
15 matches
Mail list logo
