On Mon, Apr 19, 2010 at 02:20:48AM +0100, Dave Korn wrote:
>On 18/04/2010 23:09, Yuval Emek wrote:
>
>> The context of the file xterm.exe.stackdump is:
>> Exception: STATUS_ACCESS_VIOLATION at eip=610202F7
>> eax=00CE00F8 ebx=61229E44 ecx=7530783F edx=002D20F0 esi=00000000 edi=0022FA14
>> ebp=61020A10 esp=0022C7E4 program=C:\cygwin\bin\xterm.exe, pid 4640, thread
>> main
>> cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
>> Stack trace:
>> Frame Function Args
>> End of stack trace
>
>$ addr2line --exe cygwin-1.7.5-1/winsup/cygwin/cygwin1.dbg
>610202F7
>/ext/build/netrel/src/cygwin-1.7.5-1/winsup/cygwin/dll_init.cc:78
>
> 71 /* Initialize an individual DLL */
> 72 int
> 73 dll::init ()
> 74 {
> 75 int ret = 1;
> 76
> 77 /* Why didn't we just import this variable? */
> 78 *(p.envptr) = __cygwin_environ;
> 79
>
> Ah. Hmm. That certainly does look like it's nothing to do with the DEP or
>anything else; either we're missing a null pointer check here, or there's some
>reason why that pointer's never supposed to be null at this point in the code
>but somehow it is.
p.envptr is supposed to be filled in by the call to _cygwin_crt0_common
in cygwin_attach_dll. It is supposed to be set to the address of the
"environ" variable in the DLL. It is not supposed to be NULL. That
assignment should actually not even be necessary but the fact that
envptr may be NULL is a problem. Of course, it could just be some
non-NULL garbage too. Running in gdb and getting a stack trace would be
instructive.
The handling of the environ pointer has always made my head hurt. In
retrospect, I wish I'd simplified it for 1.7.x.
cgf
--
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
