On Sep 16 21:55, Hommersom, Fred wrote:
You can help by running the new snapshot under strace, like you did before.
I have done three tests:
below the maximum
exactly the maximum
over the maximum
Further empirical tests turned out that the environment in Windows NT
is not limited, at
Thanks for the answer.
Fred
Further empirical tests turned out that the environment in Windows NT
is not limited, at least not up to a tested size of about 800K.
But there is a big problem in Windows nevertheless. When using ASCII
functions to access the environment, as Cygwin does, the
Thanks for the replies so far. Unfortunately is the best option (set
variables in bash) not feasable.
The .bat file is a complex set of bat files with logic inside so that
would take a lot of effort to convert
But I have done some experiments with bash without --login option and
the advised
On Sep 16 11:08, Hommersom, Fred wrote:
Thanks for the replies so far. Unfortunately is the best option (set
variables in bash) not feasable.
The .bat file is a complex set of bat files with logic inside so that
would take a lot of effort to convert
But I have done some experiments with
The problem can be reproduced with cygwin1-20050916.dll
The output of strace in the case of a stackdump is below.
**
Program name: c:\cygwin\bin\bash.exe (pid 2692, ppid 1)
App version: 1005.18, api: 0.132
DLL version: 1005.19, api: 0.138
DLL build:
On Sep 16 12:51, Hommersom, Fred wrote:
The problem can be reproduced with cygwin1-20050916.dll
The output of strace in the case of a stackdump is below.
**
Program name: c:\cygwin\bin\bash.exe (pid 2692, ppid 1)
App version: 1005.18, api: 0.132
No problem. here is a new trace (similar to the original) and the related
stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=610D6971
eax= ebx=10010248 ecx=F2FF edx=00245300 esi=0001 edi=00246000
ebp=0022EE68 esp=0022EE64 program=c:\cygwin\bin\bash.exe, pid 3572, thread main
On Sep 16 13:31, Hommersom, Fred wrote:
No problem. here is a new trace (similar to the original) and the related
stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=610D6971
eax= ebx=10010248 ecx=F2FF edx=00245300 esi=0001 edi=00246000
ebp=0022EE68 esp=0022EE64
On Sep 16 14:28, Corinna Vinschen wrote:
I observerd that tcsh doesn't like variables with a length of 31K,
though. ash, bash, zsh and pdksh could handle that long environment
varibale just fine, tcsh on the other hand printed this:
$ echo $VERY_LONG_ENV_VAR
Word too long.
Never mind,
Yes sure. You can see this in the header of the dump its says:
DLL version: 1005.19, api: 0.138
DLL build:20050916 00:00:39SNP
In order to be sure that we are talking about the same things:
I have all these variables in DOS and start bash from a CMD window with command
c:\cygwin\bin\strace
On Fri, Sep 16, 2005 at 03:55:14PM +0200, Hommersom, Fred wrote:
Yes sure. You can see this in the header of the dump its says:
DLL version: 1005.19, api: 0.138
DLL build:20050916 00:00:39SNP
In order to be sure that we are talking about the same things:
I have all these variables in DOS and
From your strace output, it looks to me like windows itself is
returning garbage when we ask it for the list of environment variables.
If that is the case, we can guard against that but we can't make the
passed in environment useful, unfortunately.
Is it possible that 'asking for the
It looks to me as if a buffer or stack is reused if some maximum is
exceeded with effect that the system sometimes works.
From your strace output, it looks to me like windows itself is returning
garbage when we ask it for the list of environment variables.
I don't think all places in
On Fri, Sep 16, 2005 at 04:36:00PM +, Eric Blake wrote:
It looks to me as if a buffer or stack is reused if some maximum is
exceeded with effect that the system sometimes works.
From your strace output, it looks to me like windows itself is
returning garbage when we ask it for the list of
I don't think all places in Windows have the limitation.
Look at the code. We're inspecting a buffer returned from
GetEnvironmentStrings. That is a windows function. The very first
things returned from this are garbage.
OK, I stand corrected.
$ /bin/env | wc -c
34664
$ cmd
bash:
Perhaps I do not understand it. I was talking about invoking cygin from
native.
The native environment grows far over 32 k. It just does not show up in
bash.
If I can help by testing the new snapshot: please supply some hints.
Fred
On the other hand, POSIX would claim that this usage should
On Fri, Sep 16, 2005 at 08:04:57PM +0200, Hommersom, Fred wrote:
Perhaps I do not understand it. I was talking about invoking cygin
from native. The native environment grows far over 32 k. It just does
not show up in bash. If I can help by testing the new snapshot: please
supply some hints.
You can help by running the new snapshot under strace, like you did before.
I have done three tests:
below the maximum
exactly the maximum
over the maximum
**
Here are the results of the test below the maximum
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Reid Thompson on 9/12/2005 5:15 PM:
Hommersom, Fred wrote:
The file bigsetup.bat contains a huge amount environment variables.
For a medium number (~ 600) everything works fine
For a larger number the output is:
bash: /usr/bin/id:
My startup of cygwin is a .bat file with contents
call bigsetup.bat
set HOME=C:\Data\locations\tc50_custy00
c:\cygwin\bin\bash --login -i
The file bigsetup.bat contains a huge amount environment variables.
For a medium number (~ 600) everything works fine
For a larger number the output is:
Hommersom, Fred wrote:
My startup of cygwin is a .bat file with contents
call bigsetup.bat
set HOME=C:\Data\locations\tc50_custy00
c:\cygwin\bin\bash --login -i
The file bigsetup.bat contains a huge amount environment variables.
For a medium number (~ 600) everything works fine
For a larger
21 matches
Mail list logo
