Laden...

[erledigt] VS-Debugger läuft in if, obwohl die Bedingung (angeblich?) nicht erfüllt ist (war?)

Erstellt von GG71 vor 12 Jahren Letzter Beitrag vor 12 Jahren 5.293 Views
G
GG71 Themenstarter:in
75 Beiträge seit 2007
vor 12 Jahren
[erledigt] VS-Debugger läuft in if, obwohl die Bedingung (angeblich?) nicht erfüllt ist (war?)

Hallo,

(s. Anhang)
kann mir bitte jemand erklären, was hier los ist?!
Irgendwie habe ich keine Nerven für solche Späße am Fr. Nachmittag.
Danke.

BTW:
VS2010 habe ich schon neu gestartet.
Die { } nach if habe auch schon gesetzt.
if (true == this.IsFielMoved) auch schon probiert.

BTW2:
public bool IsFileMoved { get; private set; }

Ciao:
GG 😉

Gelöschter Account
vor 12 Jahren

Stell dir vor, das zum Zeitpunkt der If-Abfrage, das teil noch True war, dannach aber wieder False ist. Der Grund kann Multithreading sein oder aber irgendwas komisches im Getter der Property.

3.170 Beiträge seit 2006
vor 12 Jahren

Hallo,

ich hab sowas schon mal gesehen, wenn sich Visual Studio verschluckt hat (ist aber schon lang her). Bereinige mal die Solution und lass ihn ganz neu bauen.

Gruß, MarsSTein

Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca

G
GG71 Themenstarter:in
75 Beiträge seit 2007
vor 12 Jahren

So Leute,

(s. Anhang)
das ist mir zu hart für ein Freitag Abend.
Ich mach' jetzt Feuerabend (und denke über ein Alternativ-Beruf nach.
Schafe züchten auf Sardinien, das wäre was Entspanntes.

Ciao:
GG 😉

5.742 Beiträge seit 2007
vor 12 Jahren

PDBs stimmen wirklich mit Source überein?

S
401 Beiträge seit 2008
vor 12 Jahren

Hast du die Variable schon mal auf der Console ausgeben lassen?

1.346 Beiträge seit 2008
vor 12 Jahren

Wenn VS bei mir misst baut schließe ich die Solution und lösche sowohl jeden bin, als auch obj Ordner. Dann neu öffnen und neu kompilieren. Meist stellt sich zwar dan nraus, dass VS alles richtig gemacht hat, und das Problem ca 20cm vor dem Rechner saß, aber manchmal hilft es. Solange nicht noch irgendwelche Fremddaten im bin Ordner liegen, die nicht durch VS automatisch reinkopiert werden kann man das problemlos machen. Die Ordner werden automatisch wieder erstellt

2.207 Beiträge seit 2011
vor 12 Jahren

Hallo zusammen,

ich tippe mal stark auf ein Multithreading-Problem.

hast du dir mal die CurrentThreadId ausgeben lassen?

Gruss

coffeebean

=== EDIT:

Egal wie die Lösung aussah...sie interessiert mich 😃

G
GG71 Themenstarter:in
75 Beiträge seit 2007
vor 12 Jahren

Hallo Leute,

vielen Dank, dass so viele von Euch versuchen zu helfen.
Status:
obj\bin Ordner wurden schon mehrmals komplett gelöscht, reboot VS bzw. PC haben auch nicht geholfen.

Was ich aber gefunden habe, und da wären wir bei Multithreading, mit lock geht's richtig:
(s. Anhang)

Wer? Wo? Was hat an meinem Instanz herumzufummeln?!
Wie kann ich das überwachen?

Ciao:
GG 😉

2.207 Beiträge seit 2011
vor 12 Jahren

Hallo GG71,

erstmal kannst du dir die ThreadID ausgeben lassen. Dann siehst du welcher Thread hier überhaupt rumwerkelt.

Weiter ist glaube ich lock(this) nicht so gern gesehen (steht auch hier im Forum glaube ich). Mach dir lieber ein Object als Klassenvariable und lock darauf.

Gruss

Coffeebean

Hinweis von herbivore vor 12 Jahren

Im Forum steht allerdings auch das Gegenteil, nämlich eine Begründung, warum lock(this) der bessere Weg ist und die Empfehlung von Microsoft, lock(syncObject) zu verwenden, nicht so sinnvoll ist. Das Thema wurde ausführlich in Sollte man lock this vermeiden? und und in Entwurfsmuster Singleton und Schlüsselwort synchronized [und sollte lock(this) verwendet werden?] (und folgende Beiträge) diskutiert.

S
401 Beiträge seit 2008
vor 12 Jahren

Weiter ist glaube ich lock(this) nicht so gern gesehen (steht auch hier im Forum glaube ich). Mach dir lieber ein Object als Klassenvariable und lock

siehe MS-Doku: lock-Anweisung

Wie kann ich das überwachen?

z.B.

  • beim Property IsFileMoved einen Break-Point setzen?
  • protokoliere den Zugriff (get/set) auf das Property / die Variable

edit:
Ist das Property IsFileMoved öffentlich oder privat?

6.862 Beiträge seit 2003
vor 12 Jahren

Hallo,

lock auf das eigene Objekt ist halt problematisch da es leicht zu Deadlocks kommen kann.

Aber ganz ehrlich, du greifst ohne Synchronisierung von mehreren Threads auf die gleiche Variable zu und wunderst dich dass es Seiteneffekte gibt? Da gehören eindeutig die Multithreading Grundlagen nochmal aufgefrischt.

PS: Scheint ja nun doch kein VS Problem zu sein, daher ab in Basistechnologien

Baka wa shinanakya naoranai.

Mein XING Profil.

Hinweis von herbivore vor 12 Jahren

Ergänzung zu lock(this): Das Argument zieht insofern nicht uneingeschränkt, als dass es auch bei lock(syncObject) Deadlocks geben kann, wenn EventHandler ins Spiel kommen. Man muss also so oder so aufpassen. Auf der anderen Seite wird dem Benutzer der Klasse eine erweitertes Synchronisieren durch ein privates syncObject unnötig erschwert. Alles weitere in den oben genannten Links.

S
401 Beiträge seit 2008
vor 12 Jahren

Aber ganz ehrlich, du greifst ohne Synchronisierung von mehreren Threads auf die gleiche Variable zu und wunderst dich dass es Seiteneffekte gibt? Da gehören eindeutig die Multithreading Grundlagen nochmal aufgefrischt.

Leider schweigt hierzu der Themenersteller. Von mehreren Thread's ist bis jetzt keine Information durchgedrungen.

@MarsStein

  • Wie viele Thread's greifen auf die Variable zu?
  • Ist es möglich, dass bei einem schreibenden Zugriff ein weiterer Thread lesend Zugriff anfordert?
  • Sind entsprechende lock's (wenn einer schreiben möchte, dann darf kein weiterer Thread auf die Variable zugreifen) im ausführenden Code hinterlegt?
G
GG71 Themenstarter:in
75 Beiträge seit 2007
vor 12 Jahren

Hallo Leute,

ich habe kein Multithread, sonst hätte ich es schon geschrieben bzw. schon länger in diese Richtung gesucht. Es ist eine Consolenanwendung ohne GUI-Thread.

Und die Sache ist noch bunter:
Der Debugger geht in die if-Bedingung, zeigt die throw Zeile als aktiv an, es wirft aber kein Exception bzw. wirft es erst weiter unten in der Methode. Ich habe mich die ganze Zeit durch die Darstellung vera****en lassen, weil ich den Fehler gesucht habe und meinte, es sieht wirklich so aus, gefunden zu haben.

Also die Erklärung ist, das "nur" die optische Darstellung im Codeeditor falsch ist, die if-Bedingung wird korrekt verarbeitet (auch ohne lock).

Sorry, dass ich Euch irregeführt habe, war kein Absicht.

Ciao:
GG AKA Georg 😉

Ciao:
GG 😉

2.207 Beiträge seit 2011
vor 12 Jahren

Hallo GG71,

kannst du mir mal deine Solution/Klasse/ dein Projekt hochladen (oder Link per PM schicken)?

Ich würde mir das gerne mal anschauen zuhause.

Gruss

coffeebean

6.862 Beiträge seit 2003
vor 12 Jahren

Okay, ich hatte

...Was ich aber gefunden habe, und da wären wir bei Multithreading, mit lock geht's richtig... so verstanden das er es verwendet.

Was meinst du mit

bzw. wirft es erst weiter unten in der Methode. Wo unten? An was für einer Stelle?

Baka wa shinanakya naoranai.

Mein XING Profil.

U
1.688 Beiträge seit 2007
vor 12 Jahren

ich habe kein Multithread

Du kopierst immer synchron auf einen FTP-Server? Wie denn genau?

Es ist eine Consolenanwendung ohne GUI-Thread.

Das schließt Multithreading nicht aus.

Benutze doch auch mal Logging (Debug.WriteLine, Console.WriteLine) anstatt der Haltepunkte. Echtzeitverhalten kann man so besser analysieren.

Gelöschter Account
vor 12 Jahren

Also die Erklärung ist, das "nur" die optische Darstellung im Codeeditor falsch ist, die if-Bedingung wird korrekt verarbeitet (auch ohne lock). Ich vermute mal ganz stark, das die Sourcedatei nicht zu der DLL passt, die gedebuggt wird. Überprüfe deine Debugging optionen!

G
GG71 Themenstarter:in
75 Beiträge seit 2007
vor 12 Jahren

Hi,

@talla:
die Code-Blöcke "Step 1: Bla-Bla", "Step 2: Bla-Bla" habe ich immer zusammengeklappt im Screenshot gehabt, war die Meinung, dass es nichts mit der Exception zu tun hat. Im Block 2 bricht die Anwendung bei der Ausführung in der Wirklichkeit ab, nicht so wie es mir der Debugger vorgaugelt.

BTW. Multithreading:
lock war nur ein Verzweiflungsschritt.

Es ist eine Consolenanwendung ohne GUI-Thread.
Das schließt Multithreading nicht aus.

Ja, damit meinte ich: Ich mache kein 2. Thread auf, WPF auch nicht.

Also die Erklärung ist, das "nur" die optische Darstellung im Codeeditor falsch ist, die if-Bedingung wird korrekt verarbeitet (auch ohne lock).
Ich vermute mal ganz stark, das die Sourcedatei nicht zu der DLL passt, die gedebuggt wird. Überprüfe deine Debugging optionen!

Habe bisher keine entsprechende "Abweichungen" in der Darstellung festgestellt, welche Einstellungen sollen hier Auswirkungen haben?

Ciao:
GG 😉

6.862 Beiträge seit 2003
vor 12 Jahren

Hallo,

und was steht im FTP Upload Block?

Ich mache kein 2. Thread auf, WPF auch nicht.

Wo kommt WPF jetzt auf einmal her? Dachte du hast ne Konsolenanwendung?

Baka wa shinanakya naoranai.

Mein XING Profil.

Gelöschter Account
vor 12 Jahren

So wie ich den Screenshot weiter oben sehe, ist wirklich entweder Multithreading am Werk oder aber die Sourcen passen nicht zur den Binaries.

Allmählich wird es hier im Thread auch etwas zu Bunt... Bitte schreib eindeutig, was du hast und was du einsetzt.

Welche Einstellung du in den Optionen überprüfen sollst, wirst du ganz schnell erkennen, wenn du dir den letzten Teil meines ersten Satzes in diesem Post durchließt.

Ansonsten hilft dir nur noch das Threading Fenster. Auch zu finden unter Debug->Windows->Threads

Dort kannst du sehen, wie viele Threads am laufen sind und in welchem du auf einmal bist.

Sollte das kein fruchtbares Ergebnis liefern, baust du dir am besten ein kleines Beispielprojekt, um den Fehler zu reproduzieren.

U
1.688 Beiträge seit 2007
vor 12 Jahren

Ja, damit meinte ich: Ich mache kein 2. Thread auf, WPF auch nicht.

WPF? Ansonsten kann aber natürlich eine FTP-Komponente bzw. -Bibliothek mit mehreren Threads arbeiten (was sie im Normalfall auch tun wird). Leider hast Du die entsprechende(n) Frage(n) nicht beantwortet.

G
GG71 Themenstarter:in
75 Beiträge seit 2007
vor 12 Jahren

Hallo Leute,

vergisst es mal mit Multithread, das versuche ich schon von Anfang an zu erklären. Es gibt weder ein GUI- oder FTP-, geschweige ein von mir selbst eröffnete 2nd Thread.

Die Erklärung war:
Der Debugger zeigt Müll an, obwohl bin\obj Ordner schon mehrmals gelöscht wurden.

Siehe Screenshots oben:
Die gelbe Aktiv-Zeile beim Step by Step (F11) Durchlaufen der Source geht jedes mal in if-Bedingung, obwohl die abgefragte Property false ist. Es springt sogar auf die throw Zeile und suggeriert damit, dass die von mir gesuchte Exception von dieser Stelle stammen würde. Da ich deshalb jedes mal gestoppt habe, um zu überprüfen, warum ich trotz nicht erfüllte Bedingung im if gelandet bin, habe ich erst später gemerkt, dass throw in der Wirklichkeit, egal was der Debugger anzeigt, hier nicht ausgeführt wird, sonder in der gleiche Methode aber weiter unten.

Ich hoffe, ich konnte jetzt die Angelegenheit klären.
Danke nochmal für die Hilfe,
Ciao:
GG AKA Georg 😉

Ciao:
GG 😉

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo zusammen,

in Fällen, denen man den Verdacht hat, dass der Debugger falsch arbeitet bzw. falsch anzeigt, sollte man versuchen, sich mit Logging- bzw. Tracing-Ausgaben Klarheit zu verschaffen, was wirklich passiert.

herbivore

6.862 Beiträge seit 2003
vor 12 Jahren

Hallo,

Die Erklärung war:
Der Debugger zeigt Müll an

Sorry, aber das ist doch keine Erklärung. Sicherlich ist keine Software vor Fehlern gefeit, aber so ein Fehler im VS Debugger wäre schon längst bekannt. Daher tippe ist immer noch, dass der Code dieses Verhalten auslöst. Was in den zugeklappten Codeblöcken steht und wie du deine MoveToFTP aufrufst, hast du ja immer noch nicht gezeigt. F11 springt auch nur in Code rein der auch ausgeführt wird.

Baka wa shinanakya naoranai.

Mein XING Profil.

S
248 Beiträge seit 2008
vor 12 Jahren

Hallo,

ich verwende zum Beispiel Code Contracts. Die kompilierten Assemblies werden dabei umgeschrieben was dazu führt, dass die angezeigten Zeilen mit den tatsächlichen manchmal nicht übereinstimmen.
Vielleicht ist es in deinem Fall ähnlich?

spooky

6.911 Beiträge seit 2009
vor 12 Jahren

Hallo Spook,

die CodeContracts und der Debugger vertragen sich sehr gut, die angezeigten Zeilen stimmen mit den tatsächlichen überein.

Die Zeilen können nicht übereinstimmen wenn ein Release-Build gedebuggt wird und die *.pdb nicht korrekt geladen wird. Aber auf diesen Punkt (die *.pdb) wurde ja schon mehrmals hingewiesen in diesem Thread (z.B. von Jack30Lena).

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

U
1.688 Beiträge seit 2007
vor 12 Jahren

Die Zeilen können nicht übereinstimmen wenn ein Release-Build gedebuggt wird und die *.pdb nicht korrekt geladen wird

Eine etwas "merkwürdige" bzw. "ungewöhnliche" Abfolge im Debugger könnte beim Debuggen eines Release-Builds auch durch die Optimierungen entstehen.
Auch aus diesem Grunde wurde schon ein paar Mal auf das Logging verwiesen.

G
GG71 Themenstarter:in
75 Beiträge seit 2007
vor 12 Jahren

Hallo,

aber so ein Fehler im VS Debugger wäre schon längst bekannt.

habe die entsprechende Stelle als Projekt extrahiert (s. Anhang).
Bin mal gespannt, wie es sich bei Euch beim Debuggen verhält.

Ciao:
GG 😉

Ciao:
GG 😉

6.911 Beiträge seit 2009
vor 12 Jahren

Hallo GG71,

Bin mal gespannt, wie es sich bei Euch beim Debuggen verhält.

Auch ohne Debugger sehe ich, dass das klar in die Exception läuft da FileType null ist.

Es wäre besser wenn du mal wirklich Tracing einbaust um schauen wann und wo (Stacktrace) der Eigenschaftswert geändert wird. Darauf wurdest du schon mehrfach hingewiesen.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

109 Beiträge seit 2010
vor 12 Jahren

Habs grad mal bei mir getestet, :::

mfg seraph

Ich beschütze das was am Wichtigsten ist!

G
GG71 Themenstarter:in
75 Beiträge seit 2007
vor 12 Jahren

Moin,

Auch ohne Debugger sehe ich, dass das klar in die Exception läuft da FileType null ist.

ja, jetzt in der abgespeckte Version, hat aber nichts mit der Problematik zu tun.
Wenn ich Console.Writeline oder was auch immer einfüge geht der Debugger nicht mehr in die if-Schleife. Ich könnte es höchsten mit der Handy abfilmen, habe jetzt aber nicht wirklich Zeit für sowas.

Edit:
Ich habe jetzt doch ein Screen-Video vom Ablauf im Debugger erstellt.

Ciao:
GG 😉

Ciao:
GG 😉

6.911 Beiträge seit 2009
vor 12 Jahren

Hallo GG71,

nicht mehr in die if-Schleife

Siehe http://www.if-schleife.de/

habe jetzt aber nicht wirklich Zeit für sowas.

Aha, darum sollen wir für dich die Ursache finden...

Hast du das Video mit der oben angehängten Klasse erstellt? Da ist das Verhalten eindeutig nicht so.

Und bau endlich mal im Setter von IsFileMoved Tracing ein - sonst bringt das gar nix. Bitte beachte [Hinweis] Wie poste ich richtig? Punkt 8.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"