Date: Thu, 1 Dec 2011 10:47:22 -0500
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: 1.7.9-1 dll::init() still causing STATUS_ACCESS_VIOLATION errors
Message-ID: <20111201154722.GA18444@ednor.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <609C4401F424CD42A1FB3F9E26889B3E03E30E39E6 AT df-ex03 DOT us DOT dataflux DOT com> <20111201092426 DOT GR17159 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20111201092426.GR17159@calimero.vinschen.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Thu, Dec 01, 2011 at 10:24:27AM +0100, Corinna Vinschen wrote:
>On Nov 30 15:33, Jim Schneider wrote:
>> I updated today to 1.7.9-1 from an earlier install.   Now, bash produces a series of dozens of exception lines like the following:
>> 
>> 214713567 [main] bash 5368 exception::handle: Exception: STATUS_ACCESS_VIOLATION
>> 214714267 [main] bash 5368 open_stackdumpfile: Dumping stack trace to bash.exe.stackdump
>> 
>> The contents of bash.exe.stackdump are:
>> 
>> Exception: STATUS_ACCESS_VIOLATION at eip=6102048B
>> eax=00C40308 ebx=6124545C ecx=75110F81 edx=003C51F8 esi=00000000 edi=0028F9F4
>> ebp=61020C00 esp=0028C7C4 program=C:\cygwin\bin\bash.exe, pid 1928, thread main
>> cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
>> Stack trace:
>> Frame     Function  Args
>> End of stack trace
>> 
>> The address 6102048B is associated with line 82 of winsup/cygwin/dll_init.cc, which is in dll::init():
>> 
>> /* Initialize an individual DLL */
>> int
>> dll::init ()
>> {
>>   int ret = 1;
>> 
>>   /* This should be a no-op.  Why didn't we just import this variable? */
>>   if (!p.envptr)
>>     p.envptr = &__cygwin_environ;
>>   else
>>     *(p.envptr) = __cygwin_environ;		/* This is line 82 */
>> 
>>   /* Don't run constructors or the "main" if we've forked. */
>>   if (!in_forkee)
>>     {
>>       /* global contructors */
>>       p.run_ctors ();
>> 
>>       /* entry point of dll (use main of per_process with null args...) */
>>       if (p.main)
>>         ret = p.main (0, 0, 0);
>>     }
>> 
>>   return ret;
>> }
>> 
>> The pointer p.envptr is tested before an attempt is made to use it, so it looks like it is getting garbage.  Disassembling the function dll::init shows that the edx register is being used to hold the address.  It's holding 003C51F8, just short of 240K before the base address of bash.
>> 
>> If I manage to run it down, I'll send a patch.
>
>I observed this problem myself a couple of times but I never found out
>what it is.  It seems to be introduced by rebasing DLLs but even that
>is an assumption.  What worked for me was to reinstall the packages
>which contain the DLLs loaded by the affected process.  After that, the
>affected process worked.  And even running rebase once more didn't break
>it again.  Which is a pity, kind of, since that would have at least
>allowed to reproduce the situation.  It would be very helpful if anybody
>could explain the effect and show how to fix it.

Actually, the problem is supposed to be greatly reduced, if not fixed,
in CVS.

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