2012-11-01 12 views
5

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

gdb crash dialogue

+0

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

+0

@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

+0

Abbastanza triste quando un bug arresta il debugger. Ti lascia sul torrente senza una pagaia. Hai bisogno di una pagaia diversa. –

risposta

0

Bene, questa potrebbe non essere la soluzione giusta per te, solo un suggerimento. ImportError: DLL load failed: Invalid access to memory location. Ho riscontrato lo stesso errore durante il tentativo di rendere la mia estensione di Python programmata in C. Piattaforma: Windows 32 bit.

È stato un vero dolore perché questo errore appariva casualmente sia in modalità interattiva che non interattiva in tutti gli ambienti Python (Spyder, Notebook, console normale ...). Ho compilato il mio codice usando MinGW e le distutils di Python (comando python setup.py install). La compilazione non ha fornito avvisi o errori e ha prodotto file pyd nella directory corretta. Ma quando provo ad importare questo modulo import example pro il mio codice Python si è bloccato in modo irregolare (di solito solo un tentativo su cinque di importare il modulo è riuscito).

Strano è che su un altro computer ha funzionato bene ... Bene, ho finalmente trovato una soluzione alternativa - Ho scaricato una versione più recente di MinGW (prima avevo usato la versione che viene compresso nella distribuzione Qt SDK) e compilato il modulo di nuovo. Quindi ha funzionato senza più arresti anomali. Tuttavia non ho trovato alcuna soluzione o spiegazione sistematica. Quindi potrei avere qualcosa a che fare con il compilatore (forse l'assenza delle sue DLL? Non so esattamente) che è stato usato per generare il file pyd.

+0

Ehi, scusate non ho postback dopo aver trovato il problema con runtime dfiferent essere collegato a. Ho messo il link al problema Python che ho inserito nella risposta qui sotto. Ho cambiato manualmente in distutils che msvc * è usato e che ha risolto il problema per me. – eudoxos

0

Avevo lo stesso errore durante l'importazione di win32api, ho appena importato i ctypes prima di eseguire l'importazione win32api e l'errore non era presente.