Re: STATUS_ACCESS_VIOLATION

["jan.kolar" <kolar at math dot cas dot cz>]

Marc Girod wrote:
> 
> Hello,
> 
> I keep my installation up-to-date on a weekly basis, and never fail to
> rebaseall/peflagsall as many times as needed to be able to start emacs
> in an X session without fork errors. Then I do a perlrebase.
> 
> However, I eventually get STATUS_ACCESS_VIOLATION errors, in 
> various contexts, e.g. (last now) doing a dired.
> I have been keeping the *stackdump files produced, and even logging
> their contents for fear they would get overwritten.
> I note that the value of eip (instruction pointer register?) reported is
> often the same. Here are the data for the last event:
> 
> ~> ls -ltr *.stackdump
> -rwxrwxrwx 1 emagiro EEI-ATusers 647 Mar 10  2011 xauth.exe.stackdump
> -rwxrwxrwx 1 emagiro EEI-ATusers 320 Jul 18 10:39 bash.exe.stackdump
> -rwxrwxrwx 1 emagiro EEI-ATusers 320 Jul 18 10:56 XWin.exe.stackdump
> -rwxrwxrwx 1 emagiro EEI-ATusers   0 Sep 22 06:44 sh.exe.stackdump
> -rwxrwxrwx 1 emagiro EEI-ATusers 325 Sep 30 10:40 emacs-X11.exe.stackdump
> ~> cat emacs-X11.exe.stackdump
> Exception: STATUS_ACCESS_VIOLATION at eip=6102048B
> eax=01B23D00 ebx=61248414 ecx=75E6B363 edx=00276818 esi=00000000
> edi=0022F9FC
> ebp=61020C00 esp=0022C7CC program=C:\cygwin\bin\emacs-X11.exe, pid 4628,
> thread main
> cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
> Stack trace:
> Frame     Function  Args
> End of stack trace
> 
> 
> Also, in the cygwin shell which from which the X session is launched,
> I got:
> 
>    2 [main] emacs-X11 4628 exception::handle: Exception:
> STATUS_ACCESS_VIOLATION
> 726 [main] emacs-X11 4628 open_stackdumpfile: Dumping stack trace to
> emacs-X11.exe.stackdump
>    2 [main] emacs 6660 child_copy: linked dll data write copy failed,
> 0x26B000..0x274C8C, done 0, windows pid 6692, Win32 error 487
> 
> 
> And I checked:
> 
> ~> net helpmsg 487
> 
> Attempt to access invalid address.
> 
> 
> My understanding, from reading previous threads in the list, is that
> some Windows process performs DLL injection, which modifies the
> memory map of the emacs process, so that it doesn't match the 
> expectation of 'ls' while being forked as part of executing 'dired'.
> 
> Is there any way to identify this Windows process, or the exact DLL,
> so as to know in advance how to rebase the processes to avoid this
> conflict? Can I use the above data for that purpose?
> Or is it doomed?
> And is my understanding flawed?
> 
> Thanks,
> Marc
> 

> I keep my installation up-to-date on a weekly basis ...
> Exception: STATUS_ACCESS_VIOLATION at eip=6102048B  ...

Well, this makes makes possible to verify if I was right when guessing 
it might be '*(p.envptr) = __cygwin_environ;', which is done during dll
inicialization. And it is indeed.
 



-----------------------
/bin/cygwin1.dll-official-cygwin-1.7.9-1
gdb cat ...
disas ...
  0x61020470 :       push   %ebx
  0x61020471 :       sub    $0x18,%esp
ebx=this
  0x61020474 :       mov    0x20(%esp),%ebx		
edx= & (this->p.envptr)
  0x61020478 :       mov    0x8(%ebx),%edx
if ( (this->p.envptr) == 0 )
  0x6102047b :      test   %edx,%edx
  0x6102047d :      je     0x610204a0 

  0x6102047f :      mov    0x611fcaf8,%eax

!in_forkee
  0x61020484 :      cmpb   $0x0,0x6116a954

*(p.envptr) = __cygwin_environ;               STATUS_ACCESS_VIOLATION
  0x6102048b :      mov    %eax,(%edx)

  0x6102048d :      mov    $0x1,%eax

if (!in_forkee)
  0x61020492 :      je     0x610204b0
  0x61020494 :      add    $0x18,%esp
  0x61020497 :      pop    %ebx
  0x61020498 :      ret

...

If you do not succeed with snapshots (I'm curious to know), 
and you do not want to wait for a solution 
a modification from my previous post might tell you the name of DLL that is
troubled, 
or you can hook the mentioned line in gdb and print out the name of DLL.
(you need debug build and .dbg file. Perhaps:
break dll_init.cc:<linenumber> if ( d && (h != d->handle) )
     or, break *0x<address> if ( d && (h != d->handle) )
p name
    or p console_printf("%W\n", name)
  (This also can be done without the debug build but I do not like trying
that. :-))
)


If you do not mind long list of possibly troubled DLLs, 
try 
cat /proc/<pid of your big (emacs) app currently running>/maps
Generally, the problem might be expected with those non-Win lines, that do
not start 6 or 7.
For example cygbz2 in the following example:

10000000-10014000 r--p 1000D5B0 7C1B:E988 281474976893107    
/usr/bin/cygbz2-1.dll
686C0000-686CB000 r--p 686C3540 7C1B:E988 281474976893714    
/usr/bin/cygfontenc-1.dll

Or, and this looks best:
 setup a debugger
    export CYGWIN='error_start=C:\cygwin\bin\gdb'    
 run the program 
    DISPLAY=:0 gitk
 If it crashes, gdb is started: 
       70032 [main] wish8.5 9444 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
       *** starting debugger for pid 9444, tid 7844     Attaching to program
`/cygdrive/c/cygwin/bin/wish8.5.exe', process 9444
       [New Thread 9444.0x1ea4]
 and you can list the maps:
 cat /proc/9444/maps
      ...
      002C0000-003AD000 r-xp 0037A910 7C1B:E988 1125899907147852   
/usr/bin/libtcl8.5.dll
      ^      
      zero is typical for troubles
      ...


JK

-- 
View this message in context: http://old.nabble.com/STATUS_ACCESS_VIOLATION-tp32557806p32579564.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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