EAccessViolation außerhalb Debugger (War : Ursache ???)

Hallo,

ich hatte gestern schon mal eine Antwort gepostet, aber die ist nicht dort gelandet wo sie sollte.
Also folgendes:

1. der Fehler tritt nur bei bestimmten Eingabesituationen auf (ist nachvollziehbar).
2. auskommentieren habe ich gestern ohne Erfolg versucht. Die Fehlersuche betrifft etwa 700 Programmzeilen in 5 voneinander abhängig abgearbeiteten Proceduren.
3. CodeGuard anwerfen geht nicht, da das Programm dann nicht mehr startet.Es kommt dann ein Fehler mit der Meldung "... kann nicht initialisiert werden..." (aus dem Gedächtnis)

Was für Codezeilen (Aufrufe) würdet Ihr denn auskommentieren?

Gruß Udo

Alexander Kempf

Hallo,

Udo_11 schrieb:

1. der Fehler tritt nur bei bestimmten Eingabesituationen auf (ist nachvollziehbar).

offenbar hast Du ja schon den ersten wichtigen Schritt getan, nämlich den Fehler
reproduzieren zu können. Damit hat man meiner Erfahrung nach eigentlich schon
fast gewonnen.

Udo_11 schrieb:

2. auskommentieren habe ich gestern ohne Erfolg versucht. Die Fehlersuche betrifft etwa 700 Programmzeilen in 5 voneinander abhängig abgearbeiteten Proceduren.

Klingt für mich nicht so hoffnungsvoll und etwas irritierend. Wenn man den Fehler reproduzieren
kann, aber nur auf 700 Zeilen eingrenzen kann, sieht das so aus, als ob man den Code überhaupt
nicht im Griff hat. Ich kann da aber natürlich auch falsch liegen, schließlich sehe ich den
Code ja nicht.

Udo_11 schrieb:

3. CodeGuard anwerfen geht nicht, da das Programm dann nicht mehr startet.Es kommt dann ein Fehler mit der Meldung "... kann nicht initialisiert werden..." (aus dem Gedächtnis)

Die Erfahrung, dass CodeGuard nicht angewendet werden kann, habe ich bisher noch nicht gemacht.
Manchmal kommt es vor, dass die CodeGuard-DLL nicht gefunden. Das lässt sich natürlich leicht
beheben. Prinzipiell würde ich nach wie vor den Einsatz von CodeGuard bei derartigen Fehlern
empfehlen.

Udo_11 schrieb:

Was für Codezeilen (Aufrufe) würdet Ihr denn auskommentieren?

Ist natürlich ohne Code schwer zu sagen. Prinzipiell gilt es ja den Fehler zu isolieren
oder einzukreisen. Naheliegend wäre es daher, möglichst viel Code auszuhängen und dann
schrittweise wieder hineinzunehmen. Das macht man solange bis der Fehler wieder auftaucht.
Dann nimmt man wieder andere Teile weg bis nur noch der Code-Teil drin ist, der Probleme
macht.
Im Extremfall bedeutet das, dass Du zu Beginn praktisch den gesamten Code wegnimmst. Das
Programm macht dann natürlich nichts mehr sinnvolles, aber es sollte auch keinen Fehler
mehr produzieren. Bei einem guten Design könntest Du möglicherweise komplette Klassen
einzeln unter die Lupe nehmen, z.B. mit einem Unit-Test. Dann könntest Du vielleicht
auch komplette Klassen aushängen oder durch leere Implementierungen (Null-Objekt) ersetzen.

Zur Not könntest Du auch einfach mal ein bisschen Code zeigen. Vielleicht kann man da
etwas sehen.

Gruß

Alexander

Hallo,

nach 6 Stunden versuchter Fehlereingrenzung folgendes Ergebnis:

1. Der Fehler tritt auf bei Aktionen mit 2 bestimmten ADODataSets (beim Setzen von Feldwerten per Code und auch beim abschließenden Post()
2. Der Fehler tritt nur auf, wenn das Programm mit Compilermodus "Endgültig" kompiliert wird. Wenn ich im Compilermodus "Endgültig" die Geschwindigkeitsoptimierung ausschalte bzw. im Modus "VollDebug" kompiliere, dann läuft das Programm in allen getesteten Situationen ohne Fehler.

Wenn jetzt wieder jemand einen Tip hat, wäre ich sehr dankbar.

Gruß Udo

Braunstein

Das könnte z.Bsp. an Defaultbelegungen von Variablen liegen. Die meisten Compiler belegen Variablen beim definieren im Debugmodus mit Defaultwerten (Pointer z.Bsp. mit 0) tun dies im Releasemodus aber nicht mehr. Wenn man sich auf sowas verlässt kann das schonmal zu fehlern kommen.

Alexander Kempf

Hallo,

Udo_11 schrieb:

1. Der Fehler tritt auf bei Aktionen mit 2 bestimmten ADODataSets (beim Setzen von Feldwerten per Code und auch beim abschließenden Post()

Dann würde ich den Code mal in ein anderes/neues Projekt kopieren und dort ausführen.
Wenn dort das Problem nicht auftritt, hast Du wahrscheinlich einen Fehler an anderer Stelle,
der sich aber erst hier auswirkt.

Udo_11 schrieb:

2. [...]dann läuft das Programm in allen getesteten Situationen ohne Fehler.

Dann hast Du wahrscheinlich den entscheidenden Test einfach nicht gemacht. Ich habe auch mal
Tage damit verbracht einen solchen Fehler zu finden.
Auch wenn ich weiß, dass er nicht das Allheilmittel ist und ich in Richtung "Ceterum censeo
Carthaginem esse delendam" gehe, würde ich Dir trotzdem nochmal nahe legen, CodeGuard irgendwie
zu benutzen. Es gibt übrigens auch Alternativen zu CodeGuard. Vielleicht funktioniert ja da
irgendwas.

Meine Vermutung geht in die gleiche Richtung wie Braunsteins. Für mich deutet alles auf nicht
initialisierten Speicher hin - deswegen auch immer wieder der Ratschlag mit CodeGuard.

Natürlich besteht immer noch die Möglichkeit, auf althergebrachte Weise Debug-Meldungen auszugeben,
z.B. in eine Log-Datei. Hast Du das mal gemacht?

Gibt es möglicherweise Einträge in QualityCentral? Hast Du alle verfügbaren Updates installiert?
Verwendest Du ADO-Fremdkomponenten? Falls ja, gibt es für die irgendwelche bekannten Bugs?

Gruß

Alexander

Hallo,

@Alexander
Ich habe Deine beharrliche Forderung nach CodeGuard beherzigt und es nochmal versucht mit dem Ergebnis:
[list]
-- wenn ich mit aktiviertem CodeGuard innerhalb der IDE starte, passiert garnichts (keine Meldung, kein Programmstart)
-- Außerhalb der IDE bricht der Programmstart mit folgender Fehlermeldung ab:

Die Anwendung konnte nicht richtig initialisiert werden (0xc0000005).Klicken Sie auf "OK", um die Anwendung zu beenden.

Ich verwende keine ADO-Fremdkomponenten.
Log-Datei habe ich schon gemacht, Variablenbelegungen i.O., jeder Ausruf der DataSets ( z.B. dataset->...) endet in einer EAccessViolation.

Gruß Udo

Alexander Kempf

Udo_11 schrieb:

wenn ich mit aktiviertem CodeGuard innerhalb der IDE starte, passiert garnichts (keine Meldung, kein Programmstart)

Das würde ich näher untersuchen. Also Breakpoint in WinMain in der <Projektname>.cpp.

Udo_11 schrieb:

jeder Ausruf der DataSets ( z.B. dataset->...) endet in einer EAccessViolation.

Welchen Wert hat dataset? Testet Du irgendwo auf Null-Pointer?
Also etwas derartiges:

if (dataset != 0)
// oder:
if (dataset == 0)

Denn speziell bei Pointern kann bei einer nicht initialisierten Variablen mal null
drinstehen oder irgendein Datenschrott.
Vielleicht wird das Objekt auch irgendwo an anderer Stelle gelöscht.
Hast Du dieses dataset-Objekt per Code oder über den Designer erstellt?
Wo erstellst Du das Objekt?
Wo löschst Du das Objekt?
Setze mal einen Breakpoint im Destruktor der Dataset-Klasse und schaue,
ob der Destruktor irgendwann aufgerufen wird (ggf. mitloggen).

Und natürlich noch Ratschläge in der Art "Haben Sie den Netzstecker eingesteckt?":
- Bist Du sicher, dass Du mit der richtigen Version testest?
- Gibt es irgendwo eine weitere Exe, die versehentlich verwendet wird?
- Hast Du mal alle Zwischendateien gelöscht (.obj etc.)?

Gruß

Alexander

@Alexander
Danke für die Hinweise, werde ich morgen umsetzen.Für heute erstmal genug gegrübelt.
Schönen Feierabend.

Gruß Udo

Hallo,

@Alexander
@Braunstein

zuerst mal folgendes: Ich habe den Fehler gefunden!

Es war nicht das ADODataSet.
Es war ein static_cast, der innerhalb einer Schleife unter bestimmten Umständen nicht ausgeführt wurde.Demzufolge war die betreffende Variable undefiniert (Braunsteins Vermutung war richtig!)

Ich danke Euch beiden für Eure Umterstützung.

PS: CodeGuard habe ich immer noch nicht zum Laufen gebracht.

@Alexander Was gibt es für Alternativen?

Gruß Udo

Alexander Kempf

Udo_11 schrieb:

@Alexander Was gibt es für Alternativen?

Such einfach mal hier im Forum. Das wurde schon ein paar mal diskutiert.

Gruß

Alexander