4. Access Violations in API-Funktionen

Access Violations in API-Funktionen

  • P

    Hallo,

    habe folgendes Problem:
    Habe hier ein Programm, welches über den Com-Port mit einem Gerät kommuniziert. Es gibt einen Thread, welcher immer den Com-Port pollt und bei Eingang eines Datenpakets dieses aufbereitet und per Windows-Nachricht verschickt.

    Betreibe ich das Ganze auf dem Computer, wo das Projekt erstellt wurde, und an einem ComPort, welcher im Computer eingebaut ist (z.B. Com1) geht es absolut fehlerfrei. Gehe ich jedoch mit dem Programm auf einen schnelleren Computer, oder schließe das externe Gerät mit einem USB<->RS232-Converter an, stürzt es ab. Sporadisch, nicht reproduzierbar.

    Habe schon einiges ausprobiert, u.a. Evaluation-Versionen von Rational Purify, Insure++, Memory Validator. Diese Tools finden "nichts".

    Insure++ findet in der "funktionierenden" Konfiguration einen Haufen von scheinbar unwichtigen Sachen, hier das Log nach dem Ausführen des Programms:
    --------
    ************************* INSURE SUMMARY ************************ v6.1.3 **
    (...)
    ***************************************************************************
    PROBLEM SUMMARY - by type

    Problem Reported Suppressed
    -------------------------------------------------
    FREE_NULL 0 2
    RETURN_FAILURE 0 2102
    -------------------------------------------------
    TOTAL 0 2104
    -------------------------------------------------
    -----------------------------

    Zur Laufzeit werden keine Fehler angezeigt, und in den "nichtfunktionierenden" Konfigurationen komme ich halt nicht zu dem Punkt, wo diese Summary angezeigt wird. Schaut man sich die scheinbaren Fehler im Quellcode an, findet man nichts ungewöhnliches!

    Das Programm stürzt jedoch immer mit dieser "Access Violation" ab, welche ja darauf hinweist, daß ein uninitialisierter Zeiger o.ä. verwendet/gelöscht/etc. wird. In dieser Richtung suche ich nun schon geraume Zeit, kann aber nix finden!

    Die Stellen an denen der Compiler nach Auftreten des Fehlers stehen bleibt, sind z.B.:
    //in Datei DOCMULTI.CPP

    void CMultiDocTemplate::AssertValid() const
    {
    CDocTemplate::AssertValid();

    POSITION pos = GetFirstDocPosition(); //<<<--hier bleibt der Debugger stehen
    while (pos != NULL)
    {
    CDocument* pDoc = GetNextDoc(pos);
    ASSERT_VALID(pDoc);
    }
    }

    ...oder manchmal auf direkt bei Adresse 5:
    00000000 ???
    00000001 ???
    00000002 ???
    00000003 ???
    00000004 ???
    00000005 ???
    00000006 ???

    und hin und wieder auch an anderen Stellen...

    Schaut man in den Callstack, stehen als aufrufende Funktionen nur Windows-eigene drin, z.B. für das erste der Beispiele:
    ----------
    CMultiDocTemplate::AssertValid() line 220 + 3 bytes
    AfxAssertValidObject(const CObject * 0x01244fd0 {CMultiDocTemplate}, const char * 0x00639abc THIS_FILE, int 852) line 108
    CDocManager::AssertValid() line 853
    AfxAssertValidObject(const CObject * 0x01242ed0 {CDocManager}, const char * 0x00634b1c THIS_FILE, int 551) line 108
    CWinApp::AssertValid() line 552
    AfxAssertValidObject(const CObject * 0x006463e8 class CFMMApp FMMMain, const char * 0x00634ed4 THIS_FILE, int 537) line 108
    CWinThread::OnIdle(long 1) line 541
    CWinApp::OnIdle(long 1) line 492 + 12 bytes
    CWinThread::Run() line 479 + 30 bytes
    CWinApp::Run() line 400
    AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00132fb1, int 1) line 49 + 11 bytes
    WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00132fb1, int 1) line 30
    WinMainCRTStartup() line 198 + 54 bytes
    KERNEL32! 77e81af6()

    ----------

    Vielleicht sollte ich noch etwas weiter ausholen, um das Programm etwas mehr zu beschreiben (Sorry für das lange Posting...):
    Es besteht aus einigen FormViews, welche mit "OpenNewChildWindow" erzeugt bzw. angezeigt werden. Wie bereits gesagt gibt es einen Thread, der Nachrichten an die FormViews verschickt, diverse Daten werden hier dann noch verarbeitet bzw. angezeigt.

    Aufgrund der Tatsache, daß die Abstürze in Windows- bzw. MFC-Funktionen stattfinden, glaube ich das mit diesem FormView-Zeug irgendwas nicht stimmt, bisher hatte ich daran gedacht, daß mit den Nachrichten irgendwas nicht funktioniert. Habe aber trotz unendlich langer Suche nix entsprechendes gefunden 😞

    Kann es sein, daß die FormViews falsch instanziiert sind und das dies den Fehler verursacht ?

    ➡ Falls irgendjemand einen Tip, Hinweis, eine idee, oder was auch immer hat, ich bin für alles dankbar, bin kurz vorm verzweifeln (...eigentlich bin ich schon verzweifelt...)

    Danke schonmal und Gruß,

    pk

    0
Anmelden zum Antworten