On 10/3/2016 2:39 AM, Mark Geisert wrote:
Tony Kelman wrote:
I see what you've been saying about different insider builds of Windows
10 but I don't think anybody here is beating up on these releases.
Win10 anniversary with a single cygwin64 installation is sufficiently
difficult for me.
> No, that looks like I'd expect it to. You need to look at the process
> map when you have fork problems, since the problem seems to be
> intermittent.
How so? Something like
for i in `seq 1000`; do
cat /proc/self/maps > procselfmaps_`date +%s.%N`.txt;
done &
before running the problematic
Tony Kelman wrote:
You've got two different cygwin1.dll somewhere on your PATH.
For more information, I have one cygwin64 installation on C:, one
cygwin32 installation on E:, and they're never both on my path at
the same time. I'm not sure where that orphan registry entry that was
showing up
Tony Kelman writes:
>> Something occupies the heap area for Cygwin, based on the low address.
>> What does /proc/self/maps tell you?
>
> $ cat /proc/self/maps
[…]
>
> Hopefully you know what you're looking at there. Anything meaningful in that?
No, that looks like I'd expect it to. You need to
>> Still a problem in 14936. Folks, this could be very bad. Anyone at all
>> testing the insider builds, or are we going to be blindsided when an
>> update goes out to everyone that breaks cygwin?
>
> How about you start with a sane PATH that doesn#t contain all the
> Windows stuff? Set a system
Tony Kelman writes:
>> Could you paste a complete sample of the error message so we can
>> determine where in the Cygwin code it's coming from?
>
> Still a problem in 14936. Folks, this could be very bad. Anyone at all
> testing the insider builds, or are we going to be blindsided when an
> update
> You've got two different cygwin1.dll somewhere on your PATH.
For more information, I have one cygwin64 installation on C:, one
cygwin32 installation on E:, and they're never both on my path at
the same time. I'm not sure where that orphan registry entry that was
showing up in cygcheck.out came
> You've got two different cygwin1.dll somewhere on your PATH. As your builds
> proceed, they likely start out using the correct cygwin1.dll but sometimes
> load
> the wrong cygwin1.dll along the way. The error message tells you how to solve
> the problem. But I usually use this method:
>
Tony Kelman wrote:
Could you paste a complete sample of the error message so we can
determine where in the Cygwin code it's coming from?
Still a problem in 14936. Folks, this could be very bad. Anyone at all
testing the insider builds, or are we going to be blindsided when an
update goes out
> You're absolutely sure your rebasing operations are being done without
> any Cygwin processes running, even background cygserver, sshd, etc?
Pretty sure. I don't have any cygwin processes set up to start at login,
and I was rebooting several times here.
> Could you paste a complete sample of
Tony Kelman wrote:
I've tried manually rebasing, setting rebase-trigger, rerunning latest
setup, rebooting, etc. During big parallel makes none of the above helped
with getting rid of intermittent heap mismatch errors during fork after I
upgraded to Windows 10 Insider build 14926. I had been on
> I've tried manually rebasing, setting rebase-trigger, rerunning latest
> setup, rebooting, etc. During big parallel makes none of the above helped
> with getting rid of intermittent heap mismatch errors during fork after I
> upgraded to Windows 10 Insider build 14926. I had been on the Insider
I've tried manually rebasing, setting rebase-trigger, rerunning latest
setup, rebooting, etc. During big parallel makes none of the above helped
with getting rid of intermittent heap mismatch errors during fork after I
upgraded to Windows 10 Insider build 14926. I had been on the Insider fast
ring
13 matches
Mail list logo
