Jak debugować obciążenie DLL nie powiodło się: Nieprawidłowy dostęp do lokalizacji w pamięci

Question

Mam MinGW64-skompilowany DLL (moduł Pythona), co daje błąd podczas ładowania:

ImportError: DLL load failed: Invalid access to memory location 

DLL jest związane wyłącznie z bibliotek 64-bitowych (Dependency Walker to potwierdza) i ma symbole debugowania. Kod jest dość złożony, C++ 11 (około 30 plików źródłowych), nie mogę go przeciąć. Udało mi się już skompilować i przetestować inny moduł z MinGW64, toolchain działa dobrze.

Niektóre osoby w internecie zgłosiły ten błąd w przypadku kodu za pomocą instrukcji SSE2 (są one obsługiwane w mojej hw i nie używam ich wyraźnie) lub odczytu z globalnych zmiennych, które nie zostały jeszcze zainicjowane (jest kilka funkcje z __attribute__((constructor)), ale te powinny działać w MinGW64 dobrze, zgodnie z tym, co przeczytałem; aktualizacja: Usunąłem wszystkie funkcje konstruktora, aby upewnić się, że nie było to przyczyną - nie ma znaczenia).

Jakie metody analizowania przyczyn powstawania błędu?

Co próbowałem:

Kiedy załadować DLL debugger (używając ctypes.WinDLL(...)), ja niestety dostać tylko bezsensowny StackTrace z gdb - oczywiście, błąd jest uwięzionych przez ntdll.dll i sygnał jest podniesiona, ale nie robi daje żadnych dalszych wskazówek co do miejsca, gdzie był błąd z:

Program received signal SIGTRAP, Trace/breakpoint trap. 
0x0000000077c23522 in ntdll!ExpInterlockedPopEntrySListFault16() 
    from C:\Windows\system32\ntdll.dll 
(gdb) warning: HEAP[python.exe]: 
warning: Invalid address specified to RtlSizeHeap(00000000003B0000, 0000000002306830) 


(gdb) bt 
#0 0x0000000077c23522 in ntdll!ExpInterlockedPopEntrySListFault16() 
    from C:\Windows\system32\ntdll.dll 
#1 0x0000000077c0c241 in ntdll!RtlZeroHeap() 
    from C:\Windows\system32\ntdll.dll 
#2 0x0000000077c0c250 in ntdll!RtlZeroHeap() 
    from C:\Windows\system32\ntdll.dll 
#3 0x0000000077c3c130 in ntdll!LdrLoadAlternateResourceModuleEx() 
    from C:\Windows\system32\ntdll.dll 
#4 0x00000000003b0000 in ??() 
#5 0x0000000002306830 in ??() 
#6 0x00000000003b0000 in ??() 
#7 0x00000000792e21c0 in ??() 
#8 0x00000000003b0000 in ??() 
#9 0x0000000077c3c0ba in ntdll!LdrLoadAlternateResourceModuleEx() 
    from C:\Windows\system32\ntdll.dll 
#10 0xffffffffffffffff in ??() 
#11 0x0000000050000061 in ??() 
#12 0x0000000000000000 in ??() 

ja również powiązane pliki obiekt o „Hello World” wykonywalnego, ale wywala GDB już podczas otwierania pliku z Reading symbols from woomain.exe (to moja wykonywalny):

Answer 1

Problem polegał na tym, że podczas kompilowania modułu python był powiązany z innym msvcrt niż MinGW - jest to zgłaszane na http://bugs.python.org/issue16472.

Answer 2

To może nie być właściwe rozwiązanie dla Ciebie, tylko podpowiedź. ImportError: DLL load failed: Invalid access to memory location. Napotkano ten sam błąd podczas próby utworzenia własnego rozszerzenia Pythona zaprogramowanego w C. Platforma: Windows 32bits.

To był prawdziwy ból, ponieważ ten błąd pojawił się losowo w trybie interaktywnym, jak również w trybie nieinteraktywnym we wszystkich środowiskach Python (Spyder, Notebook, zwykła konsola ...). Skompilowałem swój kod przy użyciu distutils MinGW i Pythona (polecenie python setup.py install). Kompilacja nie dała żadnych ostrzeżeń ani błędów i utworzyła plik PID do właściwego katalogu. Ale podczas próby importowania tego modułu import example pro mój kod Pythona nieregularnie się zawiesił (zwykle tylko jedna na pięć prób importowania modułu powiodła się).

Dziwne było to, że na innym komputerze działało dobrze ... Cóż, w końcu znalazłem obejście - pobrałem nowszą wersję MinGW (zanim użyłem wersji zapakowanej w Qt SDK) i skompilowałem moduł ponownie. Potem zadziałało bez żadnych awarii. Jednak nie znalazłem żadnego systematycznego rozwiązania ani wyjaśnienia. Więc mógłbym mieć coś wspólnego z kompilatorem (może brak jego bibliotek DLL - nie wiem dokładnie), który został użyty do wygenerowania pliku PID.

Answer 3

Otrzymałem ten sam błąd podczas importowania win32api, właśnie zaimportowałem ctypes przed wykonaniem importu win32api i błędu nie było.