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 ha
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 s
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 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-loade
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
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
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 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 w
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 f
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; i
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 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 eve
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 the
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 rej
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 t
15 matches
Mail list logo
