Debuggen von reproduzierbaren aber nicht nachvollziehbarem Fehler

[bernerbaer]

Ich habe folgendes Problem, bei einem Kunden wirft mein Programm beim Beenden einen EInvalid Pointer Fehler, eigentlich nichts Spezielles, wird irgend ein Zugriff auf ein Objekt sein das nicht mehr existiert, aber jetzt das Problem. Der Fehler ist klar reproduzierbar, aber, nur auf genau diesem Rechner, bei einem theoretisch identischem Rechner (gleiche Hardware, gleiches OS, gleicher Virenschutz) beim selben Kunden (in Moskau) und bei all meinen Testrechnern mit den unterschiedlichsten OS und Hardwareausstattungen kann ich den Fehler nicht reproduzieren, auch von andern Kunden habe ich noch nie eine Rückmeldung erhalten, die auf diesen Fehler hindeuten (das Programm ist ca 600x im Einsatz). Wie debuggt man so einen Fehler?

[Delphi-Laie]

Wie allgemein bis speziell ist denn die Fehlermeldung? Wird wenigstens irgendeine Adresse ausgegeben?

[Nersgatt]

Wir setzen dafür MadExcept ein. Mit etwas Glück hat man dann schon mal einen Callstack, wo der Fehler auftritt und kann ihn so einkreisen.
Ansonsten Logfile schreiben.
Oder zum Kunden fahren, und per Remotedebugger durchsteppen. Manchmal muss man in den sauren Apfel beißen.

[TiGü]

Eine banale Frage und sicher schon bedacht, aber Sprache von Betriebssystem und betreffender Software des Testsystems ist gleich der eingestellten Sprache des Kundensystems?

[Lemmy]

hi,

für nen Test auch mal ne Anwendung dem Kunden geben ohne Optimierung mit aktivierten Debug-Infos.

Grüße

[bernerbaer]

Das eigentliche Problem wurde auf typisch russisch pragmatische Weise ganz kurzfristig überdeckt, es wurde ein Festplattenabbild vom Rechner auf dem das Programm ohne Fehler lief gezogen und auf den andern Rechner installiert, nun funktioniert das Programm ohne Fehlermeldung. Damit ist zwar nicht mein Fehler im Code gefunden (irgendwo muss da ja ein Bug sein), aber der Druck auf die Fehlersuche ist nun beträchtlich gesunken trotzdem bleibt das Problem bestehen, irgendwann wird der Bug wohl wieder auftauchen.


@Delphi-Laie
Ja, die Fehlermeldung ist schon konkreter, die Adresse wird angegeben, hilft mir aber nicht extrem weiter, da mir schon bewusst ist, wo der Fehler passiert, ich in meinem Code aber keinen Fehler erkennen kann und auch beim normalen Debuggen keine Probleme sehe.

@Nersgatt: ich werde mir MadExcept mal anschauen und testen, was ich auf der Homepage gesehen habe tönt interessant

@TiGü: Ja, die Sprache des OS ist identisch bei Testrechnern und dem spezifischen Rechner

Zum Kunden reisen: Nun, theoretisch stimme ich dir ja zu, aber praktisch ist das in diesem Fall nicht realistisch, der Flug nach Moskau, der Aufenthalt und Rückflug übersteigen die Softwarekosten um ein Mehrfaches

[sx2008]

Man könnte den Speichermanager FastMM verwenden und die Option CheckHeapForCorruption bzw. FullDebugMode aktivieren.
(FastMM müsste bei Delphi XE3 eigentlich standardmässig verwendet werden, oder?)
Dabei kann der Bug allerdings auch wieder unsichtbar werden.

[bernerbaer]

Zitat:

Zitat von sx2008 (Beitrag 1211911)

Man könnte den Speichermanager FastMM verwenden und die Option CheckHeapForCorruption bzw. FullDebugMode aktivieren.
(FastMM müsste bei Delphi XE3 eigentlich standardmässig verwendet werden, oder?)
Dabei kann der Bug allerdings auch wieder unsichtbar werden.

Das war meine erste Reaktion auf die Fehlermeldung, hat aber nichts gebracht.

[Klaus01]

.. ein Festplattenabzug wurde von dem Rechner, auf dem das Programm den Fehler zeigte, nicht gemacht?

Grüße
Klaus

[Morphie]

Mal mit DependencyWalker geschaut, ob wirklich alle verwendeten DLLs zwischen dem Problemrechner und deinem Rechner übereinstimmen?

Angenommen jemand hat eine manipulierte oder veraltete Version einer Windows-DLL, aus der du eine bestimmte Funktion aufrufst... Dann kann dein Programm fehlerfrei sein, es knallt trotzdem, wenn du die Funktion aus der DLL ausführst.

So ein Problem hatten wir in einer VB6-Anwendung auch mal... Lies sich absolut nicht auf unseren Rechnern / VMs reproduzieren... Bis wir dann eine abweichende Windows-DLL gefunden haben, die wir gar nicht bewusst aufrufen...