Entwickler-Ecke
Sonstiges (Delphi) - Hilfe! Programm friert willkürlich ein
freedy - Do 29.01.09 12:29
Titel: Hilfe! Programm friert willkürlich ein
Narses - Do 29.01.09 14:06
Titel: Re: Hilfe! Programm friert willkürlich ein
Moin!
Hm, Code-Woodoo... :? :lol:
 freedy hat folgendes geschrieben  : |
Quelltext 1:
2:
3:
| disassembling:
00479318 public Classes.TThreadList.LockList: ; function entry point
00479328 > call -$705ad ($408d80) ; Windows.EnterCriticalSection |
Könnt ihr mal schauen, was euch auffällt. Vom Disassembling verstehe ich leider nichts, |
Ich habe auch keinen blassen Schimmer von dem Stück Assembler, aber die Kommentare sind interessant: wenn du mit einer CritialSection zwei Threads in einen Deadlock bringst, dann bleibt dir die Anwendung jedenfalls hängen. :idea:
| freedy hat folgendes geschrieben : |
Sobald ich Code-Teile herausnehme, läuft die Software wieder. Dazu noch ein Beispiel:
Auf einem PC friert das Programm ein, wenn ich einen Button drücke. Es wird probiert, ein Handle zu holen. Füge ich in einer total fremden Funktion drei Zeilen ein, die damit überhaupt nichts zu tun haben, geht es. |
Das wiederum ist ein klassischer Hinweis auf "wir-schreiben-in-Speicher-der-uns-nicht-gehört"... ;) Besonders interessante Effekte ergeben sich bei lokalen Variablen und dynamischen Arrays. :idea: Mach mal die Bereichsprüfung an. ;)
cu
Narses
matze - Fr 30.01.09 09:53
Evntuell wäre es sogar gar nicht verkehrt, wenn du deinen Code einfach mal herzeigst... :roll:
freedy - Mo 02.02.09 10:26
Titel: Re: Hilfe! Programm friert willkürlich ein
| Narses hat folgendes geschrieben : |
| Ich habe auch keinen blassen Schimmer von dem Stück Assembler, aber die Kommentare sind interessant: wenn du mit einer CritialSection zwei Threads in einen Deadlock bringst, dann bleibt dir die Anwendung jedenfalls hängen. :idea: |
Der klassische Deadlock ist mir klar. Spricht ja auch für die Reproduzierbarkeit und die Kommentare in dem Bugreport. Da der Deadlock aber sehr weit unten auftritt, weiß ich noch nicht, wie ich ihn beheben kann / soll.
Dagegen spricht - das sage ich jetzt mal so intuitiv - dass sich das Programm auf anderen Rechner komplett anders verhält.
| Narses hat folgendes geschrieben : |
| Das wiederum ist ein klassischer Hinweis auf "wir-schreiben-in-Speicher-der-uns-nicht-gehört"... ;) Besonders interessante Effekte ergeben sich bei lokalen Variablen und dynamischen Arrays. :idea: Mach mal die Bereichsprüfung an. ;) |
Die Bereichsüberprüfung ist bei mir generell eingeschaltet. An Speicher-Fehler habe ich auch schon gedacht. Weiß aber nicht, wie das ausgetestet werden kann.
| matze hat folgendes geschrieben : |
| Evntuell wäre es sogar gar nicht verkehrt, wenn du deinen Code einfach mal herzeigst... :roll: |
Die Veröffentlichung des Source-Codes gestaltet sich etwas schwierig. Zum einen tritt der Fehler nur auf, wenn ich ihn komplett kompiliere (ohne auskommentierende Kompilerschalter). Zum anderen umfasst er inzwischen mehr als 8 MB in ca. 100 Dateien. Ich halte diese Lösung daher für wenig sinnvoll.
Kennt ihr ein Tutorial oder eine andere gute Debug-Software für Delphi, mit der die Fehler besser ausgetestet werden können?
Grüße
Micha
GTA-Place - Mo 02.02.09 12:26
Würd mich auch interessieren, obs da ein geschicktes Debug-Tool gibt. Mein Programm verwendet von den Jedis TJvAVICapture und beim Wechseln zwischen den Registerkarten vom TPageControl hängt sich das Programm meistens auf. Da wollte ich auch mal ein wenig "rumdebugen".
delfiphan - Mo 02.02.09 13:08
| freedy hat folgendes geschrieben : |
Quelltext 1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
| 00492773 +03b SysCon.exe Graphics 2446 +4 TCanvas.Draw
00bbb99b +22b SysCon.exe AdvProgressBar 1101 +59 TAdvProgressBar.Paint
00bbbbd2 +04a SysCon.exe AdvProgressBar 1202 +5 TAdvProgressBar.SetPosition
00c0f1b8 +620 SysCon.exe Form_Main 7724 +167 TfrmSysConMain.UpdateToolBars
00c04ebf +027 SysCon.exe Form_Main 3516 +4 TfrmSysConMain.ControllerStatusChange
006a141e +0e2 SysCon.exe Object_SysCon 898 +11 TEventHandler.StatusChanged
00698dba +16a SysCon.exe Object_Controller 1221 +38 TController.SetStatus
00699e14 +258 SysCon.exe Object_Controller 1614 +43 TController.ReceiveBuffer
006956bb +0b7 SysCon.exe Object_Communication 750 +7 TTCPConnection.Receive
00595b58 +254 SysCon.exe Object_ProtocolAdapter 351 +83 TParseThread.ParseQueue
005958ce +016 SysCon.exe Object_ProtocolAdapter 240 +5 TParseThread.Execute | |
Du manipulierst in TParseThread Controls auf TfrmSysConMain. Das geht schon mal nicht.
-> Updates mit TThread.Synchronize durchführen (oder asynchron mit TThread.Queue/PostMessage - in diesem Fall am besten eine eigene Klasse fürs Messaging schreiben).
freedy - Mo 02.02.09 16:05
| delfiphan hat folgendes geschrieben : |
-> Updates mit TThread.Synchronize durchführen (oder asynchron mit TThread.Queue/PostMessage - in diesem Fall am besten eine eigene Klasse fürs Messaging schreiben). |
Danke! Das war die Lösung. Ich wundere mich nur, warum das Ganze fast 3 Jahre OHNE diesen Fehler funktionierte.
Grüße
Micha
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!