Seltsame Fehler in Delphi

[oXmoX]

Hallo,

das hier wird jetzt länger ...geht aber nicht anders.

Ich habe nun schon seit über zwei Wochen Tag für Tag mit "seltsamen" Fehlern in meinem Delphi-Programm zu kämpfen. Bei dem Programm handelt es sich um eine Applikation im Bereich Computer Vision, die zum Personen Tracking mit Hilfe von zwei Kameras gedacht ist. Dabei kommen zwei externe Bibliotheken zum Einsatz: DSPack 2.3.4., um mittels Direct Show auf die beiden Kameras zuzugreifen und OpenCV Beta 4, eine OpenSource-Bibliothek - geschrieben in C - die mir diverse Algorithmen zur Bildverarbeitung bereitstellt.

Mit "seltsamen" Fehlern meine ich z.B. folgendes:

• 1) Ich vertausche zwei Zeilen im Quellcode und plötzlich verschwindet irgendwo in einem TMainMenu ein Eintrag. Anstelle des Eintrags wird nur ein leeres Feld gezeichnet.
• 2) Ich Rufe eine OpenCV-Routine zur Detektion von Punkten auf einem Schachbrett auf, doch es werden keine Punkte gefunden. Darauf entferne ich an ganz anderer Stelle im Programm einen TButton oder ein TPanel von der GUI und auf einmal kann die OpenCV-Routine alle Punkte finden ...im selben Bild! Der TButton bzw. das TPanel hat jedoch mit Sicherheit nichts mit dieser Funktion zu tun. :(

Ich könnte jetzt noch andere Fehler nennen. Das lasse ich aber, weil ich dazu weiter ausholen müsste und alle Fehler einen ähnlichen Charakter, wie die beiden obigen haben.

Im allgemeinen habe ich festgestellt: sobald ich mein Programm etwas schlanker mache, verschwinden die "seltsamen" Fehler und das Programm verhält sich wieder ordnungsgemäß. In 2) reichte schon das Entfernen eines GUI-Elements dazu aus. Manchmal reicht es auch, irgendein Form aus dem Projekt zu entfernen (welches nie aufgerufen wird).

Dieses Verhalten macht die Sache für mich sehr kompliziert. Ich bin nicht in der Lage, den Fehler zu extrahieren, d.h. das Programm soweit herunerzu-"schlanken" dass es in ein Forum passt. Desshalb kann ich hier nur allgemeine Hinweise zum Programm geben und hoffen, dass mir jemand zumindest eine grobe Richtung für die Fehlersuch weisen kann.

Hier also Infos, die evtl. wichtig sein könnten:

• Ich arbeite an vielen Stellen mit Pointern. Das muss ich tun, weil die OpenCV-Bibliothek sehr oft Pointer als Argument entgegennimmt. Z.B. werden statt Arrays dort grundsätzlich Pointer gefordert, die dann einen entsprechenden Speicherbereich allokiert haben müssen. Tatsächlich habe ich anfangs einen Fehler bei der Allokierung / Deallokierung von Speicher dabei gemacht. Durch Korrektur konnte ich den Fehler 1) beheben. Ich dachte zunächst, dass das Problem damit behoben wäre. Als ich dem Programm aber neue Funktionalität hinzufügte, tauchten die Fehler (u.a. Fehler 2) wieder auf. Ich glaube allerdings nicht, dass ich noch Fehler bei der Speicherreservierung/-freigabe habe. Könnte es dennoch damit zusammenhängen?
• Ich verwende an einer Stelle einen Parallelen Prozess in form eines Timers. Dieser ist allerdings noch nicht aktiv, wenn die Fehler auftauchen.
• Ich arbeite mit Delphi 7.0 (also kein Update bisher).
• Die Code-Optimierung des Compilers ist ausgeschaltet. Die Fehler tauchen genauso auf, denn ich die Exe außßerhalb der IDE ausführe.
• Die meisten Fehler sind auch auf anderen Systemen reproduzierbar. Mein eigener Rechner verwendet WinXP SP2. Ich hab die Fehler aber auch schon auf einem Win 2000 (selbe Delphi-Version) reproduzieren können.
• Vor gut zwei Wochen habe ich die DSPack-Bibliothek mal so weit wie möglich durch eine andere ersetzt. Das Problem bestand immernoch, wesshalb ich jetzt wieder DSPack verwende. Müsste ich tatsächlich auf DSPack verzichten, so würde mich das zeitlich weit zurückwerfen.
• Wichtig ist es mir auch nochmal darauf hinzuweisen, dass die Fehler verschwinden, wenn ich das Programm kleiner mache. Jenachdem reicht schon das Löschen von ein paar (unwichtigen) Zeilen im Sourcecode.

Bin mal gespannt, was jetzt für Hinweise kommen. Bin total verzweifelt (und das ist noch untertrieben) und habe nach so langer Zeit wirklich kaum noch Lust auf Fehlersuche.

Gruß,
oXmoX

[marabu]

Hi oXmoX,

ich kenne das Gefühl.

Vielleicht überschreiben dir DSPACK-Routinen Teile deines Programms, weil du irgendwo Zeigervariablen übergibst, wo du Zeiger auf Zeigervariablen hättest übergeben müssen - eine beliebte Fehlerquelle beim Verbinden von Delphi-Programmen mit C-DLLs, vor der auch Profis nicht gefeit sind.

Grüße vom marabu

[oXmoX]

Zitat:

Zitat von marabu

Vielleicht überschreiben dir DSPACK-Routinen Teile deines Programms, weil du irgendwo Zeigervariablen übergibst, wo du Zeiger auf Zeigervariablen hättest übergeben müssen

Einige Funktionen verlangen tatsächlich Zeiger auf Zeiger. Ich denke, dass ich die entsprechenden Parameter dort aber auch richtig übergebe. Werd's trotzdem mal nachprüfen.

Danke für den Tip.

[mschaefer]

Moin, moin,

also zunächstmal dürfen keine DCU´s gleichen Namens im Suchpfad sein Zwischendurch am besten mal alle löschen.
Sonst hört sich das doch nach einem Pointerproblem an. Würde mal folgendes Probieren. Kopiere Dir Dein Projekt
und füge der Kopie zum größer machen mal eine Riensgrafik (Bild) im Programm ein.
Und jetzt nimm kritisches Formular für Formular aus dem Projekt. Pointer und Create/Destroy-Probleme zu finden
ist keine einfache Geschichte...

Grüße /// Martin

[Christian Seehase]

Moin Oxmox,

ich würde es mal mit MemProof bzw. MemChk versuchen.
Vielleicht lässt sich damit die Ursache finden, bzw. einkreisen.

[oXmoX]

Danke für den Tip mschaefer!
Werd mal ein wenig herumbasteln.

Grad eben habe ich das Start-Form durch ein neues ersetzt. Daraufhin war der Fehler natürlich weg. Als ich wieder auf das ursprüngliche Startformular geschaltet habe tauchte der Fehler auch nicht mehr auf. Auf einmal lief alles einwandfrei ...bis ich dann das Formular um einen sinnlosen Button erweitert habe. Da war der Fehler dann wieder da.

Ein weitere Workaround bringt mich hier nicht weiter ...diesem Fehler habe ich jedenfalls den Krieg erklärt :twisted: . Stellt euch mal vor, ihr würdet nun schon 2 Wochen lang erfolglos versuchen soeinem Fehler auf die Spur zu kommen. Ich schätze ich hab's nicht mehr weit bis zum Irrenhaus.

...naja, keine Sorge: noch gehts mir gut ;)

Gruß,
oXmoX

[oXmoX]

Zitat:

Zitat von Christian Seehase

ich würde es mal mit MemProof bzw. MemChk versuchen.

MemProof ist mir schonmal eine große Hilfe ...da findet man ja doch noch so einiges. Kein Wunder bei der Komplexität, die das Proframm mittlerweile erreicht hat. Ich meld mich wieder, wenn mein Heap sauber ist (wird bestimmt noch was dauern). Mit etwas Glück bekomme ich den Fehler wirklich so weg.

Gruß,
oXmoX

[orabimus]

Bei mir half es schon einmal, die Reihenfolge der unter uses ... eingebundenen Units zu ändern.

mfg

[oXmoX]

Dann hätte ich gleich mal noch eine Frage zum Thema Speicherbereinigung. Wie mache ich das denn bei Interfaces? Z.B. erstelle ich irgendwo ein IXMLDocument mit

Code:

MyXmlDoc := NewXMLDocument;

Dann habe ich über das Interface eine Referenz auf ein neu erstelltes Objekt. Muss ich mich da etwa auch um die Wieder-Freigabe kümmern? Die Methode _Realease bringt irgendwie nicht den gewünschten Effekt (sag zumindest MemProof).

[marabu]

Ich würde erwarten, dass der folgende Code keine memory leaks hinterlässt:

Delphi-Quellcode:

uses
  MSXML2;
var
  doc: IXMLDOMDocument;
begin
  // OleInitialize(nil);
  doc := CoDomDocument.Create;
  doc := nil;
end;

Grüße vom marabu

[oXmoX]

@marabu: Danke ...meine Leaks sind jetzt weg (Lag noch woanders dran bei mir).

Nächte Frage: gibt es ein Tool, das mir unbenötigte Units aus den uses-Abschnitten entfernt. Oder muß ich mir die ganze Arbeit etwa selbst machen?

[ltiefland]

Im Interface-Abschnitt ist das kein großes Problem. Lösche doch einfach die uses Klausel (oder kommentiere sie aus) und speichere die Datei neu. Nun baut Delphi alle benötigten Units in die uses Klausel ein. So kannst Du das bei jeder Datei machen. Units, die nicht zu einer Komponente gehören sollte man eh, soweit möglich, in den implementation Abschnitt verlagern, da man auf den Inhalt dieser Units so gut wie nie zugreifen muß (im Interface-Abschnitt). Übrigens: Bei diesen Units fragt Dich Delphi zur Not, ob es sie in die Uses Klausel aufnehmen soll, falls Du eine vergessen hast.

[marabu]

Zitat:

Zitat von Christian Seehase

schau Dir mal Icarus an (www.peganza.com)

marabu

[oXmoX]

Zitat:

Zitat von marabu

Zitat:

Zitat von Christian Seehase

schau Dir mal Icarus an (www.peganza.com)

marabu

Jau, sowas hab ich gesucht.

Mir ist übrigens beim Analysieren meiner uses-Klauseln aufgefallen, dass "TBitmap" zweimal deklariert wird: einmal in "Windows" und einmal in "TGraphics". ...Seltsam.

[marabu]

Windows.TBitmap - muss ein Irrtum sein...

[oXmoX]

Zitat:

Zitat von marabu

Windows.TBitmap - muss ein Irrtum sein...

...ist aber so. Zeile 12100

[Bernhard Geyer]

Zitat:

Zitat von oXmoX

Mir ist übrigens beim Analysieren meiner uses-Klauseln aufgefallen, dass "TBitmap" zweimal deklariert wird: einmal in "Windows" und einmal in "TGraphics". ...Seltsam.

In Graphics.pas wird TBitmap als Delphi-Klasse deklariert, in Windows.pas ist die Bitmap-Struktur von Windows gemeint

[marabu]

Während mein Server im Keller noch gehustet hat kam schon die Erklärung von Bernhard. Und warum ich mit Strg-F in Windows.pas nix gefunden habe - das behalte ich lieber für mich...

marabu

[oXmoX]

Das bedeutet also für mich, dass die Reihenfolge im uses-Teil eine Rolle Spielt. Ich muss ständig darauf achten, dass "Graphics" vor "Windows" steht, da ich nicht mit dem Record, sondern mit der Klasse arbeiten will.

Wie kann ich denn explizit ein TBitmap einer bestimmten Unit ansprechen?

[marabu]

Über qualified names: windows.tbitmap

[oXmoX]

Ok ...geht mit Windows.TBitmap oder Graphics.TBitmap ...habs verstanden


Edit: ...und war zu langsam ;)

[MaBuSE]

Zitat:

Zitat von oXmoX

Mit "seltsamen" Fehlern meine ich z.B. folgendes:

• 1) Ich vertausche zwei Zeilen im Quellcode und plötzlich verschwindet irgendwo in einem TMainMenu ein Eintrag. Anstelle des Eintrags wird nur ein leeres Feld gezeichnet.
• 2) Ich Rufe eine OpenCV-Routine zur Detektion von Punkten auf einem Schachbrett auf, doch es werden keine Punkte gefunden. Darauf entferne ich an ganz anderer Stelle im Programm einen TButton oder ein TPanel von der GUI und auf einmal kann die OpenCV-Routine alle Punkte finden ...im selben Bild! Der TButton bzw. das TPanel hat jedoch mit Sicherheit nichts mit dieser Funktion zu tun. :(

Ich könnte jetzt noch andere Fehler nennen. Das lasse ich aber, weil ich dazu weiter ausholen müsste und alle Fehler einen ähnlichen Charakter, wie die beiden obigen haben.

Solche "lustigen" Fehler können auch eine ganz andere Ursache haben.

mschaefer hat es eigentlich schon angesprochen.

Zitat:

Zitat von mschaefer

also zunächstmal dürfen keine DCU´s gleichen Namens im Suchpfad sein Zwischendurch am besten mal alle löschen.

Ein weiterer Punkt ist, das Delphi eine eigene Logik hat festzustellen, ob eine *.pas kompiliert werden muss oder nicht. Es ist leicht Möglich, das Delphi "alte" *.dcu Dateien verwendet, und dadurch seltsame Fehler entstehen. Wenn er nun "merkt" Huch ich muss neu kompilieren, macht er es "richtig" Das kann eine "sinnlose" Änderung wie 2 Zeilen vertauschen sein.

Ich empfehle Dir deshalb für Dein Projekt folgende dinge zu beachten.

1. lösche alle *.dcu Dateien die nicht zu Delphi gehören und zu denen zu *.pas Dateien hast.
   Tip: [Win+F] Dateisuche -> *.dcu suchen (Vor allem unit1.dcu, unit2.dcu, ... löschen)
2. In den Projektoptionen unbedingt den Pfad für "Ausgabe für Units" aus ein Verzeichnis z.B. C:\TEMP\ProjektName\dcu
3. In den Projektoptionen unbedingt den Pfad für Suchpfad möglichst klein halten am besten leer.
4. Nach Änderung der Projektoptionen unbedingt das Projekt speichern.
5. Dann Menü "Datei -> Alle schließen" ausführen und nochmals in die Projektoptionen gehen.
6. In den Projektoptionen unbedingt den Pfad für "Ausgabe für Units" auf ein Verzeichnis z.B. C:\TEMP\ToBeDeleted\dcu
7. In den Projektoptionen unbedingt den Pfad für Suchpfad leeren.
8. In den Projektoptionen unbedingt bei [X] Vorgabe ankreuzen und OK drücken.
   Damit werden für alle Projekte die *.dcu Dateien in C:\Temp\ToBeDeleted\dcu geschrieben, mit Ausnahme derer, die Du umdefinierst (s.o.)
9. Statt Compile unbedingt immer Build benutzen (Menü "Projekt -> Projekt1 erzeugen")

Wenn nun Probleme auftreten, kannst du einfach das dcu Verzeichnis löschen.

Damit sollten Deine Probleme erledigt sein.

[oXmoX]

Zitat:

Zitat von MaBuSE

Damit sollten Deine Probleme erledigt sein.

Danke für die ausfühliche Antwort.

Z.Zt. sind die Fehler - als Folge eines kleinen Refactorings - sowieso nicht mehr vorhanden. Meine Klassen sind jetzt insgesamt etwas kleiner (vorher hatten einige Klassen locker über 1000 Zeilen), mein Heap ist sauber (dank MemProof) und die uses-Abschnitte enthalten keine unnötigen Referenzen (dank Icarus). Außerdem habe ich Abhängigkeiten, die ich nicht unbeding benötige entfernt (z.B. ein DirectX-Filter zum Skalieren des Bildes).
Wie gesagt: wenn ich den Umfang reduziere verschwinden die Fehler. Aber ich befürchte trotzdem, dass sie zurückkommen. Daher mache ich ja grad diese große Aufräumaktion.

Deine Vorschläge hab ich mir mal zu Herzen genommen. Meine dcu's landen jetzt in einem Sonderverzeichnis, dass regelmäßig gelöscht wird. Mal sehen ob's was bringt. Wenn ich Glück habe taucht der Fehler ja auch nicht wieder auf.

Gruß,
oXmoX

[oXmoX]

...und noch eine Frage:

In einem Der C-Header-Files, die ich für Delphi umgesetzt habe steht die Zeile

Code:

#define IPL_DEPTH_SIGN 0x80000000

IPL_DEPTH_SIGN wird in den nachfolgenden Zeilen dann als "int" verwendet.
In meiner .pas Datei mache ich daraus...

Code:

const
  IPL_DEPTH_SIGN: Integer = $80000000;

...und bekomme vom Compiler die Warnung
"Konstantenausdruck verletzt untere Grenzen".
Mache ich was falsch? Sollte mich die Warnung kratzen?

Gruß,
oXmoX

[marabu]

Integer($80000000) ist nicht gut - das high bit ist das Vorzeichen - du definierst da (-0) und das mag der Compiler wohl nicht. Geht nicht Cardinal?

marabu


oder DWORD...

[NicoDE]

Zitat:

Zitat von oXmoX

Code:

const
  IPL_DEPTH_SIGN: Integer = $80000000;

$80000000 ist kein portabler Integer-Ausdruck.
Laß den Typ ganz weg und entscheide bei der Verwendung ob ein Cast wirklich nötig ist.

[Luckie]

Für eine neue Frage bitte einen neuen Thread erstellen. Das hier hat wohl nichts mehr mit deinem ursprünglichen Problem zu tun.

[oXmoX]

Zitat:

Zitat von marabu

das high bit ist das Vorzeichen - du definierst da (-0)

Heißt das etwa $80000000 or 42 = -42?
Wenn dem so ist, dann brauche ich diese Konstante nicht wirklich.

@Luckie: Sorry, kommt nicht wieder vor :wink:

Edit: Hat $FFFF0000 eigentlich auch eine besondere Bedeutung? ...da schimpft der Compiler nämlich auch.

Edit2: Klar schimpft er da ...das high-bit ist ja auch wieder gesetzt. :?

[Luckie]

Zitat:

Zitat von oXmoX

@Luckie: Sorry, kommt nicht wieder vor :wink:

Dann halt dich auch bitte dran und mach ein neues Topic auf!

[oXmoX]

O.K., ich schätze mein Problem hat sich erledigt. "Die Fehler" sind nun schon seit Wochen nicht mehr aufgetaucht :-D und mein Programm ist fast fertig. Ich nehme an, es lag an einem Fehler bei der Speicherfreigabe eines Pointers (dank Memproof gefunden).

Nocheinmal vielen Dank an alle, die geholfen haben.

Gruß,
oXmoX

[marabu]

Zitat:

Zitat von oXmoX

Heißt das etwa $80000000 or 42 = -42?

Das will ich dann doch nicht so im Raum stehen lassen. Negative Zahlen werden durch das two's complement repräsentiert:

42 = $0000002A und -42 = $FFFFFFD6 oder auch not (42) + 1

marabu