Marc Girod wrote:
>
>
> marco atzeri-4 wrote:
>>
>> Problem reports: http://cygwin.com/problems.html
>> so at least we have an idea of your system
>>
>> in addition, have you checked
>> http://cygwin.com/faq/faq.using.html#faq.using.bloda
>>
>> Antivirus and driver are the most likely culprits.
>>
> Yes, I know both pages...
> Maybe you are right and I have a *problem* which I ought the *report*.
> But that's not exactly the way I was looking at it.
>
> Marc
>
There is a problem inside cygwin's fork implementation and namely with the
dll realocation.
This is covered by all the BLODA and rebaseall suggestions, though the real
problem has to be solved in cygwin. Because there is fortunately a recent
change in fork implementation, there is hope for near future with this
regard and it is really advisable to try recent snapshot.
(Personally, I will stay with my own fixes of fork, until the new code
proves to be stable and the BLODA list and rebaseall workaround disappear.)
However, STATUS_ACCESS_VIOLATION frequently appears for reason that I do not
count as part of the above, although it is connected.
Some time ago, dll::init() contained
| /* This should be a no-op. Why didn't we just import this variable?
*/
| *(p.envptr) = __cygwin_environ;
It was changed to
| /* 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;
Yet this is not enough, my patched cygwin was still getting
STATUS_ACCESS_VIOLATION here,
since dll::init() was called with badly allocated DLL. BTW, I never so
p.envptr==NULL here.
I suspect it is connected to
| HMODULE h = LoadLibraryExW (d->name, NULL,
DONT_RESOLVE_DLL_REFERENCES);
|
| if (!h)
| system_printf ("can't reload %W, %E", d->name);
| else
| {
| FreeLibrary (h);
| if (h == d->handle)
| h = LoadLibraryW (d->name);
| }
(where, theoretically, DLL might be reallocated to a different address and
there is no test for this possibility) and I might test it later.
So far I have the following modification. It helps and it also suggest DLL
which might be rebased (I did not do rebase since this modification:-)).
dll *
dll_list::alloc (HINSTANCE h, per_process *p, dll_type type)
{
WCHAR name[NT_MAX_PATH];
DWORD namelen = GetModuleFileNameW (h, name, sizeof (name));
/* Already loaded? */
dll *d = dlls[name];
+
+ if ( d && (h != d->handle) ) {
+ console_printf("JK: KNOWN DLL %W in dll_list::alloc() with
h(0x%x)!=d->handle(0x%x). "
+ "(wPId=%d pid=%d ppid=%d.) "
+ "We will return NULL which causes redo instead of
'STATUS_ACCESS_VIOLATION'.\n",
+ name, h, d->handle,
+ GetCurrentProcessId(), myself->pid, myself->ppid);
+ return NULL; // To je moznost 4. nize.
+ }
if (d)
{
---
DISPLAY=:0 gitk --all
JK: KNOWN DLL C:\cygwin\bin\libtcl8.5.dll in dll_list::alloc() with
h(0x410000)!=d->handle(0x2C0000). (wPId=4988 pid=498
8 ppid=0.) We will return NULL which causes redo instead of
'STATUS_ACCESS_VIOLATION'.
JK: KNOWN DLL C:\cygwin\bin\libtcl8.5.dll in dll_list::alloc() with
h(0x480000)!=d->handle(0x2C0000). (wPId=9708 pid=970
8 ppid=0.) We will return NULL which causes redo instead of
'STATUS_ACCESS_VIOLATION'.
JK: KNOWN DLL C:\cygwin\bin\libtcl8.5.dll in dll_list::alloc() with
h(0x410000)!=d->handle(0x2C0000). (wPId=5200 pid=520
0 ppid=0.) We will return NULL which causes redo instead of
'STATUS_ACCESS_VIOLATION'.
JK: KNOWN DLL C:\cygwin\bin\libtcl8.5.dll in dll_list::alloc() with
h(0x410000)!=d->handle(0x2C0000). (wPId=9516 pid=951
6 ppid=0.) We will return NULL which causes redo instead of
'STATUS_ACCESS_VIOLATION'.
JK: KNOWN DLL C:\cygwin\bin\libtcl8.5.dll in dll_list::alloc() with
h(0x410000)!=d->handle(0x2C0000). (wPId=6972 pid=697
2 ppid=0.) We will return NULL which causes redo instead of
'STATUS_ACCESS_VIOLATION'.
JK: KNOWN DLL C:\cygwin\bin\libtcl8.5.dll in dll_list::alloc() with
h(0x480000)!=d->handle(0x2C0000). (wPId=10488 pid=10
488 ppid=0.) We will return NULL which causes redo instead of
'STATUS_ACCESS_VIOLATION'.
JK: KNOWN DLL C:\cygwin\bin\libtcl8.5.dll in dll_list::alloc() with
h(0x410000)!=d->handle(0x2C0000). (wPId=10672 pid=10
672 ppid=0.) We will return NULL which causes redo instead of
'STATUS_ACCESS_VIOLATION'.
JK: KNOWN DLL C:\cygwin\bin\libtcl8.5.dll in dll_list::alloc() with
h(0x410000)!=d->handle(0x2C0000). (wPId=6748 pid=674
8 ppid=0.) We will return NULL which causes redo instead of
'STATUS_ACCESS_VIOLATION'.
JK: KNOWN DLL C:\cygwin\bin\libtcl8.5.dll in dll_list::alloc() with
h(0x480000)!=d->handle(0x2C0000). (wPId=8072 pid=807
2 ppid=0.) We will return NULL which causes redo instead of
'STATUS_ACCESS_VIOLATION'.
JK: KNOWN DLL C:\cygwin\bin\libtcl8.5.dll in dll_list::alloc() with
h(0x480000)!=d->handle(0x2C0000). (wPId=5164 pid=516
4 ppid=0.) We will return NULL which causes redo instead of
'STATUS_ACCESS_VIOLATION'.
JK: KNOWN DLL C:\cygwin\bin\libtcl8.5.dll in dll_list::alloc() with
h(0x410000)!=d->handle(0x2C0000). (wPId=11284 pid=11
284 ppid=0.) We will return NULL which causes redo instead of
'STATUS_ACCESS_VIOLATION'.
No more errors (sometimes 30+ errors and failure, sometimes <10 and
success);
----
JK
--
View this message in context:
http://old.nabble.com/STATUS_ACCESS_VIOLATION-tp32557806p32579035.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
