Re: bash (3312) C:\tools\cygwin\bin\bash.exe: *** fatal error - cygheap base mismatch detected - 0x180331408/0x18032D408.

2019-10-19 Thread Brian Inglis
On 2019-10-19 06:44, Ilʹja Šipicin wrote:
> sb, 19 okt. 2019 g. v 17:32, Biswapriyo Nath:
>> It seems to be issue in Travis CI. See this forum post:
>> https://travis-ci.community/t/cygwin-issue-cygheap-base-mismatch-detected/5359
>> If you are in hurry you can use Appveyor CI. I'm using it without any
>> issue. One has to just add `C:\cygwin64\bin` in PATH variable in YAML file.

> thank for another hint.
> I added 'get-childitem C:\cygwin64\bin'
> https://travis-ci.com/chipitsine/travis-cygwin/builds/132645696
> gci : Cannot find path 'C:\cygwin64\bin' because it does not exist.

He suggested adding the Cygwin bin to PATH: you have to find it; does not matter
where it exists, run:

$ find /proc/cygdrive/?/ -name cygwin1.dll

or a global Windows search on My Computer/This PC/Cortana/etc.

> seems, it does not exist. no point to add it to PATH
> there's no hurry. I want to resolve it. My issue is the same as
> described on forum - builds used to work and accidentally stopped
> working (with the same error)

If you read the problem report, the issue is that the Travis provided
Git-for-Windows AKA Git-Bash AKA MSYS2/Cygwin Git/Bash/cygwin1.dll are installed
where its cygwin1.dll can be found via the path, but the shell child processes
are running using a different version of cygwin1.dll via the path, possibly
after installing new packages using a package manager like chocolatey or pacman.

Try running:

$ which -a cygwin1.dll

and maybe:

$ cygpath -alpw "$PATH"

to see what is active, and delete whichever installation is redundant.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: bash (3312) C:\tools\cygwin\bin\bash.exe: *** fatal error - cygheap base mismatch detected - 0x180331408/0x18032D408.

2019-10-19 Thread Илья Шипицин
thank for another hint.

I added 'get-childitem C:\cygwin64\bin'

https://travis-ci.com/chipitsine/travis-cygwin/builds/132645696

gci : Cannot find path 'C:\cygwin64\bin' because it does not exist.


seems, it does not exist. no point to add it to PATH

there's no hurry. I want to resolve it. My issue is the same as
described on forum - builds used to work and accidentally stopped
working (with the same error)


сб, 19 окт. 2019 г. в 17:32, Biswapriyo Nath :

> It seems to be issue in Travis CI. See this forum post:
>
>
> https://travis-ci.community/t/cygwin-issue-cygheap-base-mismatch-detected/5359
>
> If you are in hurry you can use Appveyor CI. I'm using it without any
> issue. One has to just add `C:\cygwin64\bin` in PATH variable in YAML file.
>
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>
>

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: bash (3312) C:\tools\cygwin\bin\bash.exe: *** fatal error - cygheap base mismatch detected - 0x180331408/0x18032D408.

2019-10-19 Thread Biswapriyo Nath
It seems to be issue in Travis CI. See this forum post:

https://travis-ci.community/t/cygwin-issue-cygheap-base-mismatch-detected/5359

If you are in hurry you can use Appveyor CI. I'm using it without any
issue. One has to just add `C:\cygwin64\bin` in PATH variable in YAML file.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: bash (3312) C:\tools\cygwin\bin\bash.exe: *** fatal error - cygheap base mismatch detected - 0x180331408/0x18032D408.

2019-10-19 Thread Илья Шипицин
btw, is there recommended way of unattended installation ?

so, for example, I need certain cygwin packages installed during CI process.
I decided to use chocolatey for that. Maybe there are better ways ?

сб, 19 окт. 2019 г. в 14:52, Илья Шипицин :

> thank for the hint
>
> here's output of
>
> powershell -c '$env:PATH.Split(";") | gci'
>
> (seems there no duplicates of cygwin1.dll, no even a single dll)
>
> https://travis-ci.com/chipitsine/travis-cygwin/builds/132640664
>
> сб, 19 окт. 2019 г. в 10:23, Brian Inglis  >:
>
>> On 2019-10-18 23:00, Илья Шипицин wrote:
>> > something has changed in travis-ci (it uses windows 1803 images).
>> > script below used to work earlier. any idea why it could happen ?
>> > very simple script:
>> > https://github.com/chipitsine/travis-cygwin/blob/master/.travis.yml
>> > result:
>> > https://travis-ci.com/chipitsine/travis-cygwin/builds/132624829
>>
>> Ensure that there is only one cygwin1.dll (version) in the PATH.
>>
>> --
>> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>>
>> This email may be disturbing to some readers as it contains
>> too much technical detail. Reader discretion is advised.
>>
>> --
>> Problem reports:   http://cygwin.com/problems.html
>> FAQ:   http://cygwin.com/faq/
>> Documentation: http://cygwin.com/docs.html
>> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>>
>>

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: bash (3312) C:\tools\cygwin\bin\bash.exe: *** fatal error - cygheap base mismatch detected - 0x180331408/0x18032D408.

2019-10-19 Thread Илья Шипицин
thank for the hint

here's output of

powershell -c '$env:PATH.Split(";") | gci'

(seems there no duplicates of cygwin1.dll, no even a single dll)

https://travis-ci.com/chipitsine/travis-cygwin/builds/132640664

сб, 19 окт. 2019 г. в 10:23, Brian Inglis :

> On 2019-10-18 23:00, Илья Шипицин wrote:
> > something has changed in travis-ci (it uses windows 1803 images).
> > script below used to work earlier. any idea why it could happen ?
> > very simple script:
> > https://github.com/chipitsine/travis-cygwin/blob/master/.travis.yml
> > result:
> > https://travis-ci.com/chipitsine/travis-cygwin/builds/132624829
>
> Ensure that there is only one cygwin1.dll (version) in the PATH.
>
> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains
> too much technical detail. Reader discretion is advised.
>
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>
>

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: bash (3312) C:\tools\cygwin\bin\bash.exe: *** fatal error - cygheap base mismatch detected - 0x180331408/0x18032D408.

2019-10-18 Thread Brian Inglis
On 2019-10-18 23:00, Илья Шипицин wrote:
> something has changed in travis-ci (it uses windows 1803 images).
> script below used to work earlier. any idea why it could happen ?
> very simple script:
> https://github.com/chipitsine/travis-cygwin/blob/master/.travis.yml
> result:
> https://travis-ci.com/chipitsine/travis-cygwin/builds/132624829

Ensure that there is only one cygwin1.dll (version) in the PATH.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



bash (3312) C:\tools\cygwin\bin\bash.exe: *** fatal error - cygheap base mismatch detected - 0x180331408/0x18032D408.

2019-10-18 Thread Илья Шипицин
something has changed in travis-ci (it uses windows 1803 images). script
below used to work earlier. any idea why it could happen ?

very simple script:

https://github.com/chipitsine/travis-cygwin/blob/master/.travis.yml

result:

https://travis-ci.com/chipitsine/travis-cygwin/builds/132624829

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Cygwin error: 1 [main] bash 5856 e:\cygwin64\bin\bash.exe: *** fatal error - add_item ("\??\e:\cygwin64", "/", ...) failed, errno 1

2017-01-03 Thread Michael Goydich
RE: Cygwin error:  1 [main] bash 5856 e:\cygwin64\bin\bash.exe: ***
fatal error - add_item ("\??\e:\cygwin64", "/", ...) failed, errno 1


I am looking for help on the following issue where I get an error
message from the cygwin1.dll or from the bash.exe program.  I am
hoping that the cygwin1.dll or the bash.exe have been, or can be,
fixed to alleviate this issue:

Invocations of various Shell Scripts, which are all trying to run the
Cygwin "bash.exe" program, at the same time frame produce the
following error for each of the invocations:

---
Cygwin error:
  1 [main] bash 5856 e:\cygwin64\bin\bash.exe: *** fatal error -
add_item ("\??\e:\cygwin64", "/", ...) failed, errno 1
---

Tivoli Workload Scheduler return code or exit status:
= Exit Status   : 256
---



Do you know if anyone has been able to understand, and perhaps fix,
the error I have mentioned above.  It appears to be related to
invoking more than 2 Cygwin "bash.exe" program instances at nearly the
same second (time).  We have continuous issues with this and it can
cut 1 to 20 Tickets a week for us with the multitude of file transfers
we are doing on a daily basis.

I don't want to do any type of work-around to account for this
situation -- like calling my own "bash.exe" that throttles the
invocations of Cygwin's "bash.exe" program so that only one will be
run at a time – in other words, create a method to give each
invocation of Cygwin's "bash.exe" program separate from the other
invocations and therefore stagger them so that they do not try to run
at the exact same time (second).

See below to see an example of the Jobs that all failed near the same
time due to the supposed "bash.exe" concurrency issue.

http://stackoverflow.com/questions/28861237/bash-is-crashing-on-cygwin-add-item-c-cygwin
https://www.cygwin.com/ml/cygwin/2015-03/msg00139.html
https://www.bountysource.com/issues/27508535-several-different-operations-take-too-long-sometimes-end-up-crashing
http://superuser.com/questions/194529/cygwin-fatal-error-unable-to-remap-what-does-it-mean

--Michael




-
APPENDIX A:

Invocations of various Shell Scripts which are all trying to run the
Cygwin "bash.exe" program at the same second (time) produce the
following error for each of the invocations:

$ egrep "= Exit Status" * | egrep -v "Exit Status   : 0" | cut
-f1 -d':' | xargs cat

= JOB   : X
= USER  : X
= JCLFILE   : e:\cygwin64\bin\bash.exe -l -c
"/cygdrive/e/interface/ecrm/bin/send_to_ecrm.sh -n"
= Job Number: 797669
= Fri 03/04/16 19:31:24 Mountain Standard Time

Tivoli Workload Scheduler (Windows)/JOBLNCH 9.2.0.01 (20141211)
X
Locale LANG set to the following: "en"
TWS for Windows NT/JOBMANRC.CMD 9.2
  1 [main] bash 5856 e:\cygwin64\bin\bash.exe: *** fatal error -
add_item ("\??\e:\cygwin64", "/", ...) failed, errno 1
Stack trace:
FrameFunctionArgs
022AACE  00180071FDE (00180260B02, 00180211E99, 0060001, 0228A30)
022AACE  00180046E82 (0229A98, 022AACE, 1D176871D152D74,
000)
022AACE  00180046EC2 (0229AB0, 001, 0060001,
635C3A655C3F3F5C)
022AACE  001800DC0D4 (000, 022CE00, 001800CE498,
1D1768726085D8D)
022CB00  00180125245 (000, 000, 000, 000)
022CBC0  00180047495 (000, 009F000, 7FEFD71D000, 022D240)
000  001800460DC (000, 000, 000, 7FEFD68)
000  00180046174 (000, 000, 000, 000)
000  00100472DD1 (000, 000, 000, 000)
000  00100401010 (000, 000, 000, 000)
000  00076E759ED (000, 000, 000, 000)
000  00076FAB831 (000, 000, 000, 000)
End of stack trace

= Exit Status   : 256
= System Time (Seconds) : 0 Elapsed Time (Minutes) : 0
= User Time (Seconds)   : 0
= Fri 03/04/16 19:31:40 Mountain Standard Time



= JOB   : X
= USER  : X
= JCLFILE   : e:\cygwin64\bin\bash.exe -l -c
"/cygdrive/e/interface/iriworldwide/bin/send_to_iriworldwide.sh -n"
= Job Number: 797670
= Fri 03/04/16 19:31:24 Mountain Standard Time

Tivoli Workload Scheduler (Windows)/JOBLNCH 9.2.0.01 (20141211)
X
Locale LANG set to the following: "en"
TWS for Windows NT/JOBMANRC.CMD 9.2
  1 [main] bash 4676 e:\cygwin64\bin\bash.exe: *** fatal error -
add_item ("\??\e:\cygwin64", "/", ...) failed, errno 1
Stack trace:
FrameFunctionArgs
022AACE  00180071FDE (00180260B02, 00180211E99, 0060001, 0228A30)
022AACE  00180046E82 (0229A98, 022AACE, 1D176871D1EB6D8,
0

RE: bash.exe: *** fatal error - add_item (\??\C:\cygwin, /, ...) failed, errno 1

2015-03-09 Thread Vladimir Sakharuk
One difference is that we are running(starting) up to 32 simultaneous instances 
of bash.exe/Cygwin on 32 core box.

-Original Message-
From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of 
Corinna Vinschen
Sent: Monday, March 09, 2015 5:18 AM
To: cygwin@cygwin.com
Subject: Re: bash.exe: *** fatal error - add_item (\??\C:\cygwin, /, ...) 
failed, errno 1

On Mar  5 21:30, Vladimir Sakharuk wrote:
 That was helpful! I have stopped trying rebase combinations and 
 looking for something else...

It wasn't all that helpful I think.  My description of what happens was rather 
off.  Actually the fact if a process has created or just opened the shared mem 
region isn't checked at this point in time.
Rather, a spinlock is used to generate exclusive access to the shared mem 
region at initilization time.
This spinlock implementation, basically using the InterlockedExchange call at 
its code, has served us well in the past, but something in your cluster setup 
appears to break it, though I can't imagine how.


Corinna


 
 Thank you.
 
 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On 
 Behalf Of Corinna Vinschen
 Sent: Thursday, March 05, 2015 12:04 PM
 To: cygwin@cygwin.com
 Subject: Re: bash.exe: *** fatal error - add_item (\??\C:\cygwin, 
 /, ...) failed, errno 1
 
 On Mar  5 15:40, Vladimir Sakharuk wrote:
  Hi All,
  I have found similar issues, but did not find solution that worked for me. 
  Looking for help.
  
  I am trying to run applications on windows cluster.
  I am getting random crashes like bellow.
  However most of the times it works. I assume around 1% of starts fails. 
  Starting it is again usually succeed.
  I suspected that it was forking issue, but cygwin's rebase did not help.
  I did rebase after server reboot with no Cygwin apps running. (BTW, 
  Is there any way to check if rebase successful?)
 
 That's not a rebase problem.  It's apparently a concurrency problem of sorts. 
  While pulling up the per-user shared memory region, two or more processes 
 are trying to set up the same mount points.
 
 This is not supposed to happen.  Only the first process actually
 *creating* the per-user shared memory is supposed to create the mount points. 
  The OS tells a process if it created or just opened a shared memory region, 
 but for some reason both processes seem to think they created the shmem 
 region and one of them then stumbles of the EPERM condition trying to create 
 the root mount point twice.
 
  Thank you for suggestions.
 
 I don't have a sugggestion, in fact.  Again, this error condition was 
 supposed to be impossible, but somehow it isn't in your cluster setup.

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


Re: bash.exe: *** fatal error - add_item (\??\C:\cygwin, /, ...) failed, errno 1

2015-03-09 Thread Corinna Vinschen
On Mar  9 16:12, Vladimir Sakharuk wrote:
  -Original Message-
  From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On 
  Behalf Of Corinna Vinschen
  Sent: Thursday, March 05, 2015 12:04 PM
  To: cygwin@cygwin.com
  Subject: Re: bash.exe: *** fatal error - add_item (\??\C:\cygwin, 
  /, ...) failed, errno 1
  
  On Mar  5 15:40, Vladimir Sakharuk wrote:
   Hi All,
   I have found similar issues, but did not find solution that worked
   for me. Looking for help.
   
   I am trying to run applications on windows cluster.
   I am getting random crashes like bellow.
   However most of the times it works. I assume around 1% of starts
   fails. Starting it is again usually succeed.
   I suspected that it was forking issue, but cygwin's rebase did not help.
   I did rebase after server reboot with no Cygwin apps running. (BTW, 
   Is there any way to check if rebase successful?)
  
  That's not a rebase problem.  It's apparently a concurrency problem
  of sorts.  While pulling up the per-user shared memory region, two
  or more processes are trying to set up the same mount points.
  
  This is not supposed to happen.  Only the first process actually
  *creating* the per-user shared memory is supposed to create the
  mount points.  The OS tells a process if it created or just opened a
  shared memory region, but for some reason both processes seem to
  think they created the shmem region and one of them then stumbles of
  the EPERM condition trying to create the root mount point twice.
  
   Thank you for suggestions.
  
  I don't have a sugggestion, in fact.  Again, this error condition was 
  supposed to be impossible, but somehow it isn't in your cluster setup.
 
 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of 
 Corinna Vinschen
 Sent: Monday, March 09, 2015 5:18 AM
 To: cygwin@cygwin.com
 Subject: Re: bash.exe: *** fatal error - add_item (\??\C:\cygwin, /, ...) 
 failed, errno 1
 
 On Mar  5 21:30, Vladimir Sakharuk wrote:
  That was helpful! I have stopped trying rebase combinations and 
  looking for something else...
 
 It wasn't all that helpful I think.  My description of what happens
 was rather off.  Actually the fact if a process has created or just
 opened the shared mem region isn't checked at this point in time.
 Rather, a spinlock is used to generate exclusive access to the shared
 mem region at initilization time.
 This spinlock implementation, basically using the InterlockedExchange
 call at its code, has served us well in the past, but something in
 your cluster setup appears to break it, though I can't imagine how.
 One difference is that we are running(starting) up to 32 simultaneous
 instances of bash.exe/Cygwin on 32 core box.

Shouldn't make a difference since that's what the Interlocked operations
are meant for.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpVYZk8wEqsu.pgp
Description: PGP signature


Re: bash.exe: *** fatal error - add_item (\??\C:\cygwin, /, ...) failed, errno 1

2015-03-09 Thread Corinna Vinschen
On Mar  5 21:30, Vladimir Sakharuk wrote:
 That was helpful! I have stopped trying rebase combinations and
 looking for something else...

It wasn't all that helpful I think.  My description of what happens
was rather off.  Actually the fact if a process has created or just
opened the shared mem region isn't checked at this point in time.
Rather, a spinlock is used to generate exclusive access to the shared
mem region at initilization time.
This spinlock implementation, basically using the InterlockedExchange
call at its code, has served us well in the past, but something in your
cluster setup appears to break it, though I can't imagine how.


Corinna


 
 Thank you.
 
 -Original Message-
 From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of 
 Corinna Vinschen
 Sent: Thursday, March 05, 2015 12:04 PM
 To: cygwin@cygwin.com
 Subject: Re: bash.exe: *** fatal error - add_item (\??\C:\cygwin, /, ...) 
 failed, errno 1
 
 On Mar  5 15:40, Vladimir Sakharuk wrote:
  Hi All,
  I have found similar issues, but did not find solution that worked for me. 
  Looking for help.
  
  I am trying to run applications on windows cluster.
  I am getting random crashes like bellow.
  However most of the times it works. I assume around 1% of starts fails. 
  Starting it is again usually succeed.
  I suspected that it was forking issue, but cygwin's rebase did not help.
  I did rebase after server reboot with no Cygwin apps running. (BTW, Is 
  there any way to check if rebase successful?)
 
 That's not a rebase problem.  It's apparently a concurrency problem of sorts. 
  While pulling up the per-user shared memory region, two or more processes 
 are trying to set up the same mount points.
 
 This is not supposed to happen.  Only the first process actually
 *creating* the per-user shared memory is supposed to create the mount points. 
  The OS tells a process if it created or just opened a shared memory region, 
 but for some reason both processes seem to think they created the shmem 
 region and one of them then stumbles of the EPERM condition trying to create 
 the root mount point twice.
 
  Thank you for suggestions.
 
 I don't have a sugggestion, in fact.  Again, this error condition was 
 supposed to be impossible, but somehow it isn't in your cluster setup.

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgps2t0Gm8M4t.pgp
Description: PGP signature


RE: bash.exe: *** fatal error - add_item (\??\C:\cygwin, /, ...) failed, errno 1

2015-03-05 Thread Vladimir Sakharuk
That was helpful! I have stopped trying rebase combinations and looking for 
something else...

Thank you.

-Original Message-
From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of 
Corinna Vinschen
Sent: Thursday, March 05, 2015 12:04 PM
To: cygwin@cygwin.com
Subject: Re: bash.exe: *** fatal error - add_item (\??\C:\cygwin, /, ...) 
failed, errno 1

On Mar  5 15:40, Vladimir Sakharuk wrote:
 Hi All,
 I have found similar issues, but did not find solution that worked for me. 
 Looking for help.
 
 I am trying to run applications on windows cluster.
 I am getting random crashes like bellow.
 However most of the times it works. I assume around 1% of starts fails. 
 Starting it is again usually succeed.
 I suspected that it was forking issue, but cygwin's rebase did not help.
 I did rebase after server reboot with no Cygwin apps running. (BTW, Is 
 there any way to check if rebase successful?)

That's not a rebase problem.  It's apparently a concurrency problem of sorts.  
While pulling up the per-user shared memory region, two or more processes are 
trying to set up the same mount points.

This is not supposed to happen.  Only the first process actually
*creating* the per-user shared memory is supposed to create the mount points.  
The OS tells a process if it created or just opened a shared memory region, but 
for some reason both processes seem to think they created the shmem region and 
one of them then stumbles of the EPERM condition trying to create the root 
mount point twice.

 Thank you for suggestions.

I don't have a sugggestion, in fact.  Again, this error condition was supposed 
to be impossible, but somehow it isn't in your cluster setup.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


Re: bash.exe: *** fatal error - add_item (\??\C:\cygwin, /, ...) failed, errno 1

2015-03-05 Thread Corinna Vinschen
On Mar  5 15:40, Vladimir Sakharuk wrote:
 Hi All,
 I have found similar issues, but did not find solution that worked for me. 
 Looking for help.
 
 I am trying to run applications on windows cluster.
 I am getting random crashes like bellow.
 However most of the times it works. I assume around 1% of starts fails. 
 Starting it is again usually succeed.
 I suspected that it was forking issue, but cygwin's rebase did not help.
 I did rebase after server reboot with no Cygwin apps running. (BTW, Is there 
 any way to check if rebase successful?)

That's not a rebase problem.  It's apparently a concurrency problem of
sorts.  While pulling up the per-user shared memory region, two or more
processes are trying to set up the same mount points.

This is not supposed to happen.  Only the first process actually
*creating* the per-user shared memory is supposed to create the mount
points.  The OS tells a process if it created or just opened a shared
memory region, but for some reason both processes seem to think they
created the shmem region and one of them then stumbles of the EPERM
condition trying to create the root mount point twice.

 Thank you for suggestions.

I don't have a sugggestion, in fact.  Again, this error condition was
supposed to be impossible, but somehow it isn't in your cluster setup.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpAkeXxNJfCE.pgp
Description: PGP signature


bash.exe: *** fatal error - add_item (\??\C:\cygwin, /, ...) failed, errno 1

2015-03-05 Thread Vladimir Sakharuk
Hi All,
I have found similar issues, but did not find solution that worked for me. 
Looking for help.

I am trying to run applications on windows cluster.
I am getting random crashes like bellow.
However most of the times it works. I assume around 1% of starts fails. 
Starting it is again usually succeed.
I suspected that it was forking issue, but cygwin's rebase did not help.
I did rebase after server reboot with no Cygwin apps running. (BTW, Is there 
any way to check if rebase successful?)

Thank you for suggestions.

Running on 
cygwin 6.1
    windows server 2008 R2 Ent


2 [main] bash 12840 C:\cygwin\bin\bash.exe: *** fatal error - add_item 
(\??\C:\cygwin, /, ...) failed, errno 1
Stack trace:
Frame Function  Args
002868A8  6102F97B  (002868A8, , , )
00286B98  6102F97B  (6119FE20, 8000, , 611A1C8F)
00287BC8  6100652C  (611DF498, 00287BF4, , 60FE000C)
00287BE8  61006568  (611DF498, 00289C10, 0001, 0003000A)
0028AC28  610917E4  (60FE000C, 2C08, 0028ACF8, 61083290)

0028AC58  610D40FF  (004C46B0, 01D05699, 004657E0, 612729D4)
208979 [main] bash 12840 exception::handle: Exception: STATUS_ACCESS_VIOLATION


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: bash.exe: *** fatal error - couldn't dynamically determine load address for 'GetKeyboardLayout'

2010-10-22 Thread Thorkil Naur
Hello,

On Sat, Oct 09, 2010 at 01:40:48PM -0400, Christopher Faylor wrote:
 ...
 The cygcheck output that we request here:  http://cygwin.com/problems.html
 might provide more insight.
 ...

With permission from the owner, I attach a slightly anonymized version
of the cygcheck output that you request. 

In addition to this, I tried running mintty (that I have not tried
before) and that actually succeeds to execute bash.exe. There are some,
presumably independent, problems with this that I intend to report
separately, but I will just hesitate slightly, in case the present
problem gets resolved and the solution manages to solve those other
problems as well.

Any additional comments on this matter are most welcome.

Best regards
Thorkil

Cygwin Configuration Diagnostics
Current System Time: Sat Oct 09 21:12:15 2010

Windows XP Professional Ver 5.1 Build 2600 Service Pack 3

Path:   C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\Program Files\CA\SharedComponents\ScanEngine
C:\Program Files\CA\SharedComponents\CAUpdate\
C:\Program Files\CA\SharedComponents\ThirdParty\
C:\Program Files\CA\SharedComponents\SubscriptionLicense\
C:\Program Files\CA\eTrustITM
C:\Program Files\IBM\Personal Communications\
C:\Program Files\IBM\Trace Facility\
C:\PROGRA~1\IBM\SQLLIB\BIN
C:\PROGRA~1\IBM\SQLLIB\FUNCTION
C:\PROGRA~1\IBM\SQLLIB\SAMPLES\REPL
c:\progra~1\cool51\gen
C:\Program Files\cool60\Gen
C:\Program Files\cool65\Gen
C:\Program Files\CA\AllFusion Gen\Gen\
C:\Program Files\CA\AllFusion Gen\

Output from C:\cygwin\bin\id.exe
UID: 82191(z6pqr)GID: 10513(Domain Users)
10513(Domain Users)  0(root)  544(Administrators)
547(Power Users) 545(Users)

SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS

Path = 'C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program 
Files\CA\SharedComponents\ScanEngine;C:\Program 
Files\CA\SharedComponents\CAUpdate\;C:\Program 
Files\CA\SharedComponents\ThirdParty\;C:\Program 
Files\CA\SharedComponents\SubscriptionLicense\;C:\Program 
Files\CA\eTrustITM;C:\Program Files\IBM\Personal Communications\;C:\Program 
Files\IBM\Trace 
Facility\;C:\PROGRA~1\IBM\SQLLIB\BIN;C:\PROGRA~1\IBM\SQLLIB\FUNCTION;C:\PROGRA~1\IBM\SQLLIB\SAMPLES\REPL;c:\progra~1\cool51\gen;C:\Program
 Files\cool60\Gen;C:\Program Files\cool65\Gen;C:\Program Files\CA\AllFusion 
Gen\Gen\;C:\Program Files\CA\AllFusion Gen\'

ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
APPDATA = 'C:\Documents and Settings\z6pqr\Application Data'
CASHCOMP = 'C:\Program Files\CA\SharedComponents\'
CLASSPATH = 
'.;C:\PROGRA~1\IBM\SQLLIB\java\db2java.zip;C:\PROGRA~1\IBM\SQLLIB\java\db2jcc.jar;C:\PROGRA~1\IBM\SQLLIB\java\sqlj.zip;C:\PROGRA~1\IBM\SQLLIB\java\db2jcc_license_cu.jar;C:\PROGRA~1\IBM\SQLLIB\bin;C:\PROGRA~1\IBM\SQLLIB\java\common.jar'
CMCOMMON = 'C:\Program Files\XYZ\XYZ.AQ.EDHSager\XYZ.AQ.CMCOMMON'
CommonProgramFiles = 'C:\Program Files\Common Files'
COMPUTERNAME = 'abcdef'
ComSpec = 'C:\WINDOWS\system32\cmd.exe'
COOL-BASE = 'C:\Program Files\CA\AllFusion Gen\Gen\'
DB2INSTANCE = 'DB2'
EXCINIT = 'pqr'
FP_NO_HOST_CHECK = 'NO'
HOMEDRIVE = 'C:'
HOMEPATH = '\Documents and Settings\z6pqr'
HOMESHARE = '\\xyz1h\priv1'
IBMCMROOT = 'C:\Program Files\XYZ\XYZ.AQ.EDHSager\XYZ.AQ.CMCOMMON'
IEF = 'C:\Program Files\CA\AllFusion Gen\Gen\'
IEFGEN = 'C:\Program Files\CA\AllFusion Gen\Gen\'
IEFGXTP = 'C:\Program Files\CA\AllFusion Gen\Translat\'
IEFH = 'C:\Program Files\CA\AllFusion Gen\GEN'
IEFJRE = 'C:\Program Files\CA\SharedComponents\JRE\1.5.0_06\'
IGW_LOC = 'C:\Program Files\CA\SharedComponents\iTechnology\'
INCLUDE = 'C:\PROGRA~1\IBM\SQLLIB\INCLUDE;C:\PROGRA~1\IBM\SQLLIB\LIB'
INOCULAN = 'C:\Program Files\CA\eTrustITM'
ITMLICENSE = 'C:\Program Files\CA\SharedComponents\SubscriptionLicense\'
ITMTHIRDPARTY = 'C:\Program Files\CA\SharedComponents\ThirdParty\'
LIB = ';C:\PROGRA~1\IBM\SQLLIB\LIB'
LOGONSERVER = '\\XYZ1L'
NUMBER_OF_PROCESSORS = '2'
OS = 'Windows_NT'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PCOMM_Root = 'C:\Program Files\IBM\Personal Communications\'
PROCESSOR_ARCHITECTURE = 'x86'
PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 23 Stepping 6, GenuineIntel'
PROCESSOR_LEVEL = '6'
PROCESSOR_REVISION = '1706'
ProgramFiles = 'C:\Program Files'
PROMPT = '$P$G'
SESSIONNAME = 'Console'
SystemDrive = 'C:'
SystemRoot = 'C:\WINDOWS'
TEMP = 'C:\DOCUME~1\z6pqr\LOCALS~1\Temp'
TMP = 'C:\DOCUME~1\z6pqr\LOCALS~1\Temp'
USERDNSDOMAIN = 'INTERN.XYZ.DK'
USERDOMAIN = 'XYZ'
USERNAME = 'Z6PQR'
USERPROFILE = 'C:\Documents and Settings\z6pqr'
VSTO_LOGALERTS = '1'
windir = 'C:\WINDOWS'

HKEY_CURRENT_USER\Software\Cygwin
HKEY_CURRENT_USER\Software\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygwin\setup
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start
 Menu\Programs\Cygwin
  (default) = (unsupported type)

bash.exe: *** fatal error - couldn't dynamically determine load address for 'GetKeyboardLayout'

2010-10-09 Thread Thorkil Naur
Hello merry Cygwin'ers,

On a recently installed Cygwin (version 1.7.7-1 according to setup.exe),
the Cygwin bash shell fails to start. Details become visible when
starting bash.exe from an ordinary command prompt:

 C:\cygwinbin\bash.exe --login -i
   3 [main] bash 1928 C:\cygwin\bin\bash.exe: *** fatal error - couldn't 
 dynamically determine load address for 'GetKeyboardLayout' (handle 
 0x7E41), Win32 error 127
 Stack trace:
 Frame Function  Args
 002238B8  6102749B  (002238B8, , , 00223938)
 00223BA8  6102749B  (61177B80, 8000, , 61179977)
 00224BD8  61004AFB  (610011A0, 611575DC, 7E41, 61033DBC)
 End of stack trace
 
 C:\cygwin

Other commands work fine, for example:

 C:\cygwinbin\ls.exe
 Cygwin.bat  Cygwin.ico  bin  cygdrive  dev  etc  home  lib  proc  tmp  usr  
 var
 
 C:\cygwin

The installed bash has version 3.2.51-24, again according to setup.exe.
This is on a Windows system that describes itself as:

 Microsoft Windows XP
 Professional
 Version 2002
 Service Pack 3

On http://msdn.microsoft.com/en-us/library/ms646296%28VS.85%29.aspx,
we find:

 GetKeyboardLayout Function
 
 Retrieves the active input locale identifier (formerly called the keyboard 
 layout) for the specified thread. If the idThread parameter is zero, the 
 input locale identifier for the active thread is returned.
 Syntax
 
 HKL WINAPI GetKeyboardLayout(
   __in  DWORD idThread
 );
 ...
 Library
 User32.lib

And, using an admittedly primitive method:

 C:\cygwinbin\strings.exe /cygdrive/c/WINDOWS/system32/user32.dll | 
 bin\grep.exe GetKeyboardLayout
 GetKeyboardLayout
 GetKeyboardLayoutList
 GetKeyboardLayoutNameA
 GetKeyboardLayoutNameW
 
 C:\cygwin

This indicates that GetKeyboardLayout seems to be available. The Windows
PATH includes C:\WINDOWS\system32.

I have earlier installed Cygwin and used it's bash.exe successfully on a
number of other Windows systems, both Windows XP and, more recently,
Windows 7. On one of the other Windows XP systems, I upgraded Cygwin and
bash to the same versions mentioned above and bash.exe still works. That
particular system describes itself as:

 Microsoft Windows XP
 Home edition
 Version 2002
 Service Pack 3

(so Home edition compared to Professional).

Searching for similar messages, I found several cases, none of which
relates to the specific function GetKeyboardLayout: There is

 http://www.mail-archive.com/cygwin [ at ] cygwin.com/msg99373.html

which has

  4 [main] -bash 3392 C:\cygwin\bin\bash.exe: *** fatal error - couldn't
  dynamically determine load address for 'WSAGetLastError' (handle
  0x), Win32 error 126

And http://archives.postgresql.org/pgsql-cygwin/2005-03/msg00020.php has:

 Re: couldn't dynamically determine load address for 'NetApiBufferFree' 
 (handle 0x), Win32 error 126

And http://cygwin.ru/ml/cygwin/2007-05/msg00219.html with:

 $ rlogin blah [ at ] blah
 9617 [main] rlogin 5392 e:\cygwin\bin\rlogin.exe: *** fatal error - couldn't 
 dynamically determine load address for 'rcmd' (handle 0x75E7), Win32 
 error 127
 Hangup

In each of these cases, the problem seems to be that the mentioned
function is somehow unavailable. But the remedies mentioned does
not seem to apply to my case.

Any help to proceed in this matter will be greatly appreciated.

Thanks and best regards
Thorkil


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: bash.exe: *** fatal error - couldn't dynamically determine load address for 'GetKeyboardLayout'

2010-10-09 Thread Christopher Faylor
On Sat, Oct 09, 2010 at 06:24:40PM +0200, Thorkil Naur wrote:
Hello merry Cygwin'ers,

On a recently installed Cygwin (version 1.7.7-1 according to setup.exe),
the Cygwin bash shell fails to start. Details become visible when
starting bash.exe from an ordinary command prompt:

 C:\cygwinbin\bash.exe --login -i
   3 [main] bash 1928 C:\cygwin\bin\bash.exe: *** fatal error - couldn't 
 dynamically determine load address for 'GetKeyboardLayout' (handle 
 0x7E41), Win32 error 127
 Stack trace:
 Frame Function  Args
 002238B8  6102749B  (002238B8, , , 00223938)
 00223BA8  6102749B  (61177B80, 8000, , 61179977)
 00224BD8  61004AFB  (610011A0, 611575DC, 7E41, 61033DBC)
 End of stack trace

First guess would be that you may have a virus, BLODA* or something else
which has modified a system dll.  This function should be available
in Windows XP.

The cygcheck output that we request here:  http://cygwin.com/problems.html
might provide more insight.

cgf

*http://cygwin.com/acronyms/#BLODA

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: bash.exe: *** fatal error - couldn't dynamically determine load address for 'GetKeyboardLayout'

2010-10-09 Thread Thorkil Naur
Hello,

On Sat, Oct 09, 2010 at 01:40:48PM -0400, Christopher Faylor wrote:
 ...
 The cygcheck output that we request here:  http://cygwin.com/problems.html
 might provide more insight.
 ...

Sorry, I overlooked that. Unfortunately, the machine where this happens
is the one I use at work and looking over the cygcheck output, I suspect
that some of this information would be considered confidential by the
owner. So, I don't feel that I should disclose this information.

I will, of course, follow up on the hint about a possible virus, thanks.
I might also try to adjust the firewall and anti-virus settings, to see
if I can possibly figure out a likely cause of the problem.

For now, that leaves me without a solution to the problem, but I'll just
have to do without bash.exe and hope that not too many other programs
hit this obstacle.

Thanks a lot anyway for your efforts.

Best regards
Thorkil

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



bash.exe: ***fatal error

2008-04-30 Thread Lester Ingber
I thought it important enough to clarify item (4) below.  The attachment
is in the previous posting.

Yesterday I installed the final version of SP3 on my XP Professional
system, which I downloaded via a link to the microsoft .exe via zdnet,
just an hour or so before it was announced that MS is working on a filter
to prevent updates to machines also running some retail software (not
on my machine).  Everything is working fine, except for the issue below.

(1) Whenever I try to start a cygwin window via the default shortcut icon,
which points to C:\cygwin\cygwin.bat (which is the same since 2005),
I am getting

6 [main] ? (4596) C:\cygwin\bin\bash.exe: ***fatal error -
couln't allocate heap, Win32 error 487, base 0x6D, top
0x6E, reserve_size 61440, allocatesize 65536, page_cost 4096

The PID 4596 of course changes with each attempt.

(2) If I try to start my X session via my long-time working script
/usr/local/bin/startxwin.sh (a path-modified /usr/X11R6/bin/startxwin.sh),
it fails the same way.

However:

(3) If I start an X window via Xming, and use its menu to start a cygwin
window via
cygwin  execd   C:\cygwin\bin\bash --login -i 
this works just fine also.

(4) If I temporarily change a line in /cygwin.bat to use
sh --login -i
instead of the default
bash --login -i
and use the desktop shortcut to cygwin.bat, this also work OK.
Note these are same executables:
9:48:04 @lester:/bin% ls -l sh.exe bash.exe 
-rwxrwxrwx 1 ingber Users 470528 Jan  3 20:17 bash.exe*
-rwxrwxrwx 1 ingber None  470528 Jan  3 20:17 sh.exe*
9:48:10 @lester:/bin% zdiff bash.exe sh.exe 
9:48:23 @lester:/bin% 

(5) I have several .csh and .sh scripts in /usr/local/bin that are run via
schedules and these run just fine, e.g., updatedb.sh (just modifies the
default paths in /bin/upfatedb, but is run via `#! /bin/sh` on line 1).
I just ran updatedb.sh directly again from a window (started via (3)
above) and it works just fine.  I also temporarily changed the first
line in my updatedb.sh to `#! /bin/bash` and this also seems to run OK.

I have tried, without any change in the problem:
(6) rebaseall via ash in a command window, which seems to have run just fine.
(7) reinstalling bash, cygrunsrv, cygutils, cygwin
(8) increasing memory by +512 in the 3 parameters in the registry

Any other suggestions?

I attach the output of `cygcheck -svr`.

Thanks.

Lester


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: bash.exe: ***fatal error

2008-04-30 Thread Robin Walker

--On 30 April 2008 09:51 -0700 Lester Ingber [EMAIL PROTECTED] wrote:


Yesterday I installed the final version of SP3 on my XP Professional
system, which I downloaded via a link to the microsoft .exe via zdnet


Which build number of SP3 was that in fact? (Don't trust what the site 
said, look at what has been downloaded and installed.  Look at the detailed 
file version of a file that has been updated by SP3, for instance, 
termdd.sys).



(1) Whenever I try to start a cygwin window via the default shortcut icon,
which points to C:\cygwin\cygwin.bat (which is the same since 2005),
I am getting

6 [main] ? (4596) C:\cygwin\bin\bash.exe: ***fatal error -
couln't allocate heap, Win32 error 487, base 0x6D, top
0x6E, reserve_size 61440, allocatesize 65536, page_cost 4096


Just a stab in the dark:

1. Try renaming cygwin.bat as cygwin.cmd, and then calling 
cygwin.cmd.  Interpreting a .bat file will be done in the 16-bit 
emulation layer of XP, which then has to spawn 32-bit applications.  Try 
doing it all within the 32-bit environment by using .cmd files instead of 
.bat.


2. Did the installation of SP3 change the ordering of items in your PATH? 
Is there more than one bash.exe on your hard disk?


--
Robin Walker (Junior Bursar), Queens' College, Cambridge CB3 9ET, UK
[EMAIL PROTECTED]  http://www.queens.cam.ac.uk/  Tel:+44 1223 335528

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



Re: bash.exe: ***fatal error

2008-04-30 Thread Eric Blake

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Lester Ingber on 4/30/2008 10:05 AM:
| (1) Whenever I try to start a cygwin window via the default shortcut icon,
| which points to C:\cygwin\cygwin.bat (which is the same since 2005),
| I am getting
|
|   6 [main] ? (4596) C:\cygwin\bin\bash.exe: ***fatal error -
|   couln't allocate heap, Win32 error 487, base 0x6D, top
|   0x6E, reserve_size 61440, allocatesize 65536, page_cost 4096

Sounds like possible interference from BLODA?
http://cygwin.com/acronyms/#BLODA
http://cygwin.com/faq/faq.using.html#faq.using.bloda

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgZH0IACgkQ84KuGfSFAYAZ8QCfZ1AxjQfqLki/AfuHpe9FUJns
3g4An2YslaneRRH4oZ10AnNSoZ2NCg74
=gblQ
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/