🚀 go-pugleaf

Hello,

Can you file a bug report explaining this?  See 
http://sources.redhat.com/gdb/bugs/

Andrew

> gill_bates@hotmail.com (Gill Bates) wrote in message news:<8e6815bd.0203052011.4d0e2c0f@posting.google.com>...
> 
>> Does anyone know why the cygwin version of gdb doesn't pass exported
>> variables to the program being debugged? I have a simple test case
>> where the program can retrieve an environment variable via getenv().
>> The program works when NOT running with gdb. If I run the same
>> executable with gdb, either window or non-window mode, the same
>> variable is not defined -- not retrievable via getenv().
>> 
>> Thanks for any help!!
>> 
>> 
> 
> 
> OK;  mystery mostly solved...
> After much arduous debugging gdb using gdb (that was pretty weird and
> confusing...), I found the function 'child_create_inferior (char
> *exec_file, char *allargs, char **env)' in win32-nat.c was building
> the env string correctly then passed it to the win32api CreateProcess.
> It appears the win32 function is 'limited' to the number of env
> variables it will accept and will silently discard any that are beyond
> this undocumented limit. Anyone know what the number is? I thought
> not... In any case, the problem appears to be isolated to this bogus
> win32 api function. But; it leaves me wondering how the cygwin exec
> function gets around the dilemma. What I plan to do is dump the
> variables into a file, then suck them into the exec'ed program and
> define them using putenv()...
> 
> Thanks for the HELP!!!
>