This is the mail archive of the
mailing list for the Cygwin project.
RE: Odd behaviour of __cygwin_environ?
On 05 December 2007 12:31, Corinna Vinschen wrote:
> On Dec 4 18:17, Dave Korn wrote:
>> I'm trying to track down a bug where a child process doesn't inherit all
>> the environment variables set in its parent, so I figured I'd add a bunch
>> of strace debugging. I wrote this routine to dump an envp-style
>> pointer-array environment block: [...]
>> Am I giving myself a race here? I thought it would be OK to dump
>> __cygwin_environ from inside cur_environ because we're in the "if
>> (*main_environ != __cygwin_environ)" clause, which IIUIC is switching over
>> from the earlystartup minimal win32 environment to the full posix
> Did you read the comment right in front of the cur_environ() function?
Yep, but I didn't get the implication!
> This happens every time the application code has changed the
> environment, not using the setenv/putenv functions, but rather by
> replacing the global environ pointer with it's self-built environment
> block. Usually this also means that the former environment block has
> been free'd by the application. This means that at this point you see
> __cygwin_environ with some non-0 probability referencing garbage.
Ah, that's reassuring.
> If you want to see the actual environment block, print __cygwin_environ
> after the if-clause. If you encounter an incomplete environment block
> at this point, it might also be of some interest to see from where
> cur_environ() has been called.
> Do you have a very big environment?
> Keep in mind that the size of the
> native environment block is restricted to 32K.
I thought when cygexec was in effect the posix environment and commandline
were passed around-behind-the-back-of CreateProcess, bypassing that limit? Or
does it only handle the commandline but not environment?
Can't think of a witty .sigline today....
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html