This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Odd behaviour of __cygwin_environ?

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 environment,

Did you read the comment right in front of the cur_environ() function?
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.

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.


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

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]