Ho un (modulo python) DLL MinGW64-compilato, che dà l'errore quando viene caricato:Come eseguire il debug di carico DLL fallita: Accesso non valido alla posizione di memoria
ImportError: DLL load failed: Invalid access to memory location
La DLL è legata solo alle librerie a 64 bit (Dipendenza Walker lo conferma) e ha i simboli di debugging. Il codice è abbastanza complesso C++ 11 (circa 30 file sorgente), non posso dividerlo in due. Ho già compilato e testato con successo altri moduli con MinGW64, la toolchain funziona correttamente.
Alcune persone in tutto il Web hanno segnalato questo errore per codice utilizzando le istruzioni SSE2 (quelle sono supportate sul mio hw, e non le uso esplicitamente) o la lettura da vars globali che non sono ancora state inizializzate (ce ne sono alcune funziona con __attribute__((constructor))
, ma quelli dovrebbero funzionare in MinGW64 bene, secondo quello che ho letto; aggiornamento: Ho rimosso tutte le funzioni del costruttore per essere sicuro che non fosse la causa - non fa differenza).
Quali sarebbero i metodi per analizzare da dove viene l'errore?
Quello che ho cercato:
Quando ho caricare la DLL nel debugger (utilizzando ctypes.WinDLL(...)
), purtroppo ottenere solo stacktrace senza senso da gdb - ovviamente, l'errore viene intercettato da ntdll.dll
e il segnale viene sollevato, ma non è così dare ulteriori suggerimenti su dove l'errore è venuto da:
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 ??()
ho legato anche i file oggetto con un "ciao mondo" eseguibile, ma si blocca gdb già quando si apre il file con Reading symbols from woomain.exe
(questo è il mio eseguibile):
Eudoxos, hai provato a collegarti a dll in modo veramente dinamico, solo in fase di esecuzione? Giocare con [LoadLibraryEx] (http://msdn.microsoft.com/en-us/library/windows/desktop/ms684179%28v=vs.85%29.aspx) e le sue bandiere.Il tuo exe dovrebbe sicuramente iniziare al debugger e fallire non prima che 'LoadLibraryEx' venga chiamato esplicitamente. – Jarekczek
@Jarekczek: il caricamento della DLL in python è completamente dinamico (era il primo caso). Ho provato a collegare il file '.exe' direttamente solo per vedere se fa la differenza - non lo fa. – eudoxos
Abbastanza triste quando un bug arresta il debugger. Ti lascia sul torrente senza una pagaia. Hai bisogno di una pagaia diversa. –