2012-11-01 8 views
5

Ich habe eine MinGW64-kompilierte DLL (Python-Modul), die Fehler gibt, wenn geladen:Wie DLL laden debuggen fehlgeschlagen: Ungültige Zugriff auf Speicherplatz

ImportError: DLL load failed: Invalid access to memory location 

Die DLL nur auf 64-Bit-Bibliotheken (Dependency verknüpft ist Walker bestätigt das) und hat Debugging-Symbole. Der Code ist ziemlich komplex C++ 11 (etwa 30 Quelldateien), ich kann es nicht teilen. Ich habe bereits andere Module mit MinGW64 kompiliert und getestet, die Toolchain funktioniert einwandfrei.

Einige Leute im Internet berichteten über diesen Fehler für Code mit SSE2-Anweisungen (die auf meinem hw unterstützt werden, und ich verwende sie nicht explizit) oder das Lesen von globalen vars, die noch nicht initialisiert wurden (es gibt ein paar funktioniert mit __attribute__((constructor)), aber diese sollten in MinGW64 gut funktionieren, je nachdem, was ich gelesen habe update: Ich entfernte alle Konstruktorfunktionen, um sicherzustellen, dass es nicht die Ursache war - es macht keinen Unterschied.

Was wären Methoden zu analysieren, wo kommt der Fehler her?

Was ich versucht:

Wenn ich die DLL in Debugger laden (ctypes.WinDLL(...) verwenden), leider nur sinnlos stacktrace von GDB ich - natürlich der Fehler durch ntdll.dll und Signal eingeschlossen wird erhöht, aber es funktioniert nicht gibt weitere Hinweise auf, wo der Fehler kam aus:

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 ??() 

ich auch die Objektdateien mit einer „Hallo Welt“ ausführbar, aber gdb Abstürze bereits verbunden, wenn Sie die Datei mit Reading symbols from woomain.exe Öffnen (das ist meine ausführbare Datei):

gdb crash dialogue

+0

Eudoxos, haben Sie versucht, DLL dynamisch, nur zur Laufzeit zu verbinden? Spielen mit [LoadLibraryEx] (http://msdn.microsoft.com/en-us/library/windows/desktop/ms684179%28v=vs.85%29.aspx) und seinen Flags.Ihre Exe würde definitiv am Debugger starten und nicht früher als "LoadLibraryEx" wird explizit aufgerufen. – Jarekczek

+0

@ Jarekczek: Laden der DLL in Python ist voll dynamisch (das war der erste Fall). Ich habe versucht, direkt mit der '.exe'-Datei zu verlinken, nur um zu sehen, ob es einen Unterschied macht - aber nicht. – eudoxos

+0

Ziemlich traurig, wenn ein Bug den Debugger abstürzt. Lässt Sie ohne Paddel den Bach hinauf. Du brauchst ein anderes Paddel. –

Antwort

0

Nun, das ist vielleicht nicht die richtige Lösung für Sie, nur ein Hinweis. ImportError: DLL load failed: Invalid access to memory location. Ich habe den gleichen Fehler beim Versuch, meine eigene Erweiterung von Python in C programmiert zu machen. Plattform: Windows 32bits.

Es war ein echter Schmerz, weil dieser Fehler in allen Python-Umgebungen (Spyder, Notebook, einfache Konsole ...) sowohl im interaktiven als auch im nicht-interaktiven Modus zufällig auftrat. Ich kompilierte meinen Code mit MinGW und Pythons Distutils (Befehl python setup.py install). Die Kompilierung gab keine Warnungen oder Fehler und erzeugte pyd-Datei im richtigen Verzeichnis. Aber beim Versuch, dieses Modul import example pro meinem Python-Code zu importieren, stürzte es unregelmäßig ab (normalerweise war nur einer von fünf Versuchen, das Modul zu importieren, erfolgreich).

Seltsam war, dass auf einem anderen Computer es gut geklappt hat ... Nun, endlich habe ich einen Workaround gefunden - ich habe eine neuere Version von MinGW heruntergeladen (bevor ich die Version verwendet, die in Qt SDK Distribution gepackt) und kompiliert Modul noch einmal. Dann klappte es ohne weitere Abstürze. Ich habe jedoch keine systematische Lösung oder Erklärung gefunden. Also könnte ich etwas mit dem Compiler zu tun haben (vielleicht fehlen seine DLLs? Ich weiß es nicht genau), mit dem die pyd-Datei erzeugt wurde.

+0

Hey, tut mir leid, dass ich nicht zurück gepostet habe, nachdem das Problem mit dfiferent Laufzeiten gefunden wurde. Ich lege den Link auf die Python-Frage, die ich in der Antwort unten eingereicht habe. Ich habe manuell in distutils geändert, die msvc * verwendet wird und das Problem für mich behoben. – eudoxos

0

Ich bekam den gleichen Fehler beim Import win32api, ich habe nur Ctypes importiert, bevor Import Win32api und Fehler nicht dort war.