mkymikky/DupFinder

Vermuteter Deadlock im Programm

Closed this issue · 7 comments

Wenn die Suche beendet ist, gibt es keinen Hinweis. Gerade bei längeren Suchen auf Nicht-SSD Festplatten muss man die CPU-Last oder Laufwerksaktivität checken um zu wissen, ob er noch sucht oder bereits fertig ist.

Vermutlich ist es eher ein Bug, dass es zu einem Abbruch oder Dead-Lock des Programms kommt. Bei simplen Verzeichnissen läuft das Programm durch und gibt als Ergebnis die benötigte Zeit in Sekunden an.
Wenn ich aber z.B. C:\ als Verzeichnis wähle, hört er irgendwann auf mit Ausgaben, CPU- und Festplattenlast sind nicht gegeben und das Programm hat keine Meldung bzgl. benötigter Zeit ausgegeben.

Aktuell läuft die Suche innerhalb eines sehr kleinen Verzeichnisses (Git-Repository) nur bei einem von 8 mal erfolgreich durch.

Würdest du bitte einen Stacktrace von so einem Deadlock bereitstellen?

Das Problem konnte ich reproduzieren, nachdem ich einige Stacktraces eliminiert habe.
Die genaue Ursache suche ich gerade.

Es sieht so aus, dass der Fehler durch mehrere Probleme ausgelöst wird.

  • Bei der Fehlerbehandlung werden die unlesbaren Dateien nicht entfernt und lösen dadurch eine Endlosschleife aus.
  • Zusätzlich kann es bei binären Dateien vorkommen, dass mit 0x00 beginnen, was im DuplicateContentFinder aktuell für unbearbeitete Dateien verwendet wird.
  • Da die Variable groupedListOfFileStreams von allen Threads geteilt wird, kann es zu Überschreibungen kommen.

Lösungen:

  • Im Konstruktor einen unbenutzten Wert verwenden (alle Integer außer [-1, 255])
  • Eingabe und Ausgabevariablen sauber trennen. Dies erfordert eine strukturiertere Gruppenbehandlung.

Erst beide Lösungen in Kombination führen zu einem effizienten und (in Bezug auf oben genanntem) fehlerfreiem Suchen.

Die Duplikatssuche wurde bereits besser strukturiert, im Moment werden Check im Code ergänzt, um fehlerhaftes Verhalten zu erkennen und dann abzustellen.
Bisher wurden "Dubletten mit nur einem Element" erkannt, die auf einen Verarbeitungsfehler hinweisen. Der eigentliche Deadlock oder Endlosschleife wurde dagegen noch nicht reproduziert.

@niklaspolke : Bitte bei weiteren bestehenden Deadlocks erneut benachrichtigen.