Re: 1.7.9-1 dll::init() still causing STATUS_ACCESS_VIOLATION errors

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

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.


Corinna

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

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