Servus beisammen, gleich zum thema: ich hab mir ein Programm geschrieben (für die Kommandozeile und in C-Code), das ziemlich lange rechnen muss. Damit aber die berechnungen etwas schneller gehen habe ich alle ausgaben erstmal eliminiert und nurnoch das fertige Ergebnis (keine Zwischenergebnisse mehr) wird ausgespuckt. Doch leider bricht mir Win7 die berechnungen ab und meldet "<progname> funktioniert nicht mehr". Einen "Fortsetzen, das passt schon" butten gibts nicht. nun meine Frage: wie kann ich das unterbinden? es muss doch möglich sein auch mal 2-3 minuten ungestört von Windoof rechnen zu können oder?! nur wie? Ich danke auch schonmal für eure Antworten. PS: der Algorithmus ist vorgegeben. Die Rechenzeit ist also quasi festgelegt.
Gibts n Debugger? Keine Ahnung was Win7 da macht, ich hab mal irgendwo gelesen, dass Win7 Prozesse selbstständig killen kann, wenn keine Rückmeldung kommt. Vielleicht muss deine Berechnungsroutine zeitweilig mal pausieren? Ralf
Die Meldung erscheint normalerweise auch nur, wenn das Programm
tatsächlich abgestürzt ist, nicht wenn es einfach nur rechnet oder in
einer Endlosschleife hängt! Einfach mal ein int main() { while (true) {
} return 0; } testen.
Da bekommt der Begriff Endlossschleife endlich mal einen fassbaren Wert.
öhm schrieb: > Da bekommt der Begriff Endlossschleife endlich mal einen fassbaren > Wert. Bottom wie in Haskell geht hier leider nicht ;->
> Die Meldung erscheint normalerweise auch nur, wenn das Programm > tatsächlich abgestürzt ist... Ah, okay. Dann hat " 1.Semeterler" schon mal einen Ansatzpunkt, denn das heisst, dass seine Berechnung noch irgendwo n Bug hat. Ich weiss nicht, in wie weit man normales C ordentlich debuggen kann, aber im schlimmsten Fall soll er halt während der Berechnung Statusmeldungen in eine Datei schreiben. Beispielsweise die Eingangs- und die aktuell berechneten Werte. Die jeweiligen Meldungen können ja auch Bezug auf die entsprechende Stelle im Sourcecode nehmen, sodass er sieht, wo abgeschmiert wurde. Und wenn er zwei oder drei dieser "Logs" hat, kann er vielleicht den Bug finden... Ralf
@1.Semeterler: "<programmname> funktioniert nicht mehr" heißt: Es ist abgestürzt, es hat einen Bug. Den wirst du wohl suchen müssen. Das ist DIE Gelegenheit, den Umgang mit dem Debugger zu lernen. Das ist übrigens sehr sinnvoll investierte Zeit, wenn du vorhast, noch weitere Programme zu schreiben. Welche Entwicklungsumgebung verwendest du?
> Damit aber die berechnungen etwas schneller gehen habe ich > alle ausgaben erstmal eliminiert Das ist natürlich ungeschickt. Wenn das Programm in der Konsole wirklich so viel ausgibt, daß das das Programm verlangsamt, dann kann man die Ausgabe in eine Datei umleiten, das Konsolenfenster während der Laufzeit minimiert lassen oder die Software um die Ausgabe reduzierende Kommandozeilenschalter erweitern. So aber ist das eine Änderung der Software, die natürlich auch Fehler mit sich gebracht haben kann (und es hier wohl auch getan haben wird). > Ich weiss nicht, in wie weit man normales C ordentlich > debuggen kann, Einen Debugger vorausgesetzt: Exzellent.
Hallo, keine Ahnung von den (Un)Tiefen des Windows, aber: wir haben hier eine Anwendung laufen, die im Hintergrund mit einem Oracleserver diskutiert. Im Taskmanager des Client steht unter W2000 und XP schon nach kurzer Zeit generell "keine Rückmeldung". Das kann nun stimmen oder auch nicht. Man kann dann warten und irgendwann geht es weiter, weil die Daten doch kommen. Wenn nicht, hängt der Task eben ewig. Wenn Win 7 solche Zustände automatisch an den Nutzer meldet, weil es ihm zu lange dauert, wäre es auch eine Erklärung. Ich kenne mich aber mit dem Mechanismus nicht aus, mit dem Windows ja offenbar überprüft, ob ein Prozess noch antwortet. Gruß aus Berlin Michael
Ein sleep(0); kann Wunder wirken. Es kehrt sofort zurück wenn es nichts wichtigeres zu tun giebt. An geigneter Stelle eingebaut, könnte es das Problem lösen.
Ich hatte schon öfter das gleiche Problem ab WinVista grusel ... Was immer hilft, ist das Ding als Admin zu starten, das ist zwar fumellig, aber unter Win7 kann man das automatisieren (Rechtsklick im Explorer auf die *.exe -> Eigenschaften -> Reiter "Kompatibilität" -> "Berechtigungsstufe" Haken bei "Programm als Admin ausführen). Damit kann man schon mal 50% der Problemfälle erschlagen. Wenn das nicht hilft, müssen größere Geschütze aufgefahren werden: Nach stundenlangen Suchen bin ich über die Windows - Datenausführungsverhinderung (kein Scherz !) gestolpert. Rechtsklick auf dem "Computer" auf dem Desktop -> Eigenschaften -> links auf "Erweiterte Systmeinstellungen" -> Im Bereich "Leistung" auf den Button "Einstellungen" -> Reiter "Datenausführungsverhinderung" ... Ufff ... Dort den Radio-Button "DatenauführungsDingBums für alle Programme und Dienste ..." aktivieren unten in die Liste deine *.exe eintragen. Normalerweise hat Vista/Win7 dannach nie mehr einen Dienst als nicht mehr funktionsfähig bemängelt. Aber Debuggen kann auch nie schaden ;-)
DINISO schrieb:
> Ich hatte schon öfter das gleiche Problem ab WinVista grusel ...
Das ist alles nur herumdoktorn an Symptomen. Die Ursache ist deswegen
immer noch nicht beseitigt.
Christian R. schrieb: > Das ist alles nur herumdoktorn an Symptomen. Die Ursache ist deswegen > immer noch nicht beseitigt. Das hilft aber nichts, solange ich auf ein Programm angewiesen bin, dessen Quellcode ich nicht vor der Nase habe und ich es nur so zum Laufen bringe.
DINISO schrieb: > Christian R. schrieb: >> Das ist alles nur herumdoktorn an Symptomen. Die Ursache ist deswegen >> immer noch nicht beseitigt. > > Das hilft aber nichts, solange ich auf ein Programm angewiesen bin, > dessen Quellcode ich nicht vor der Nase habe und ich es nur so zum > Laufen bringe. Das ist richtig. Aber der TE hat den Quellcode ja.
Das ganze ist eine typische Windows7-Zickerei. Ich hatte es schon oefter, dass ein Programm keine Rueckmeldung mehr gab, weil es so intensiv am machen war. Das ist aber okay, denn nach etwas Zeit meldet sich das Programm brav zurueck. Es sei denn Windows kriegt das mit, dann bietet es einem mindestens an, das Programm abzuschiessen, oder macht das selber mal...
Das ist keine "Windows-Zickerei", das ist ein Fehler im Programm.
wenn du kein yield() (win16 & win32) machst oder die Warteschlange nicht mit regelmäßig mit GetMessage() leerst, kriegst du einen "Keine Rückmeldung ..."-Eintrag im Taskmanager. Grüße vom wirklich schlauen Windoof, das genau weiß, wenn dein Programm abgeschmiert ist, und nicht bloß rechnet.
zwieblum schrieb: > wenn du kein yield() (win16 & win32) machst oder die Warteschlange nicht > mit regelmäßig mit GetMessage() leerst, kriegst du einen "Keine > Rückmeldung ..."-Eintrag im Taskmanager. 1. Das Programm ist für die Kommandozeile 2. Geht es um die Meldung "xyz funktioniert nicht mehr" 3. Die Meldung "Keine Rückmeldung" kommt zwar, wenn man nicht auf Ereignisse reagiert, das Programm wird aber nicht von Windows abgeschossen 4. Schonmal nachgesehen was Yield() macht? Das war eine reine Win16-Geschichte.
Rufus t. Firefly schrieb:
> Das ist keine "Windows-Zickerei", das ist ein Fehler im Programm.
Wir haben das unter Win7 mit RADStudio2010 (Borland, Embarcadero)
beobachtet. Programm im Debugger gestartet, Programm läuft auf
Brechpunkt, man schaut sich ein paar Variablen an usw. und lässt das
Programm dann weiterlaufen. In genau diesem Augenblick meckert Win7 dann
"...exe reagiert nicht mehr" und beendet den Prozess gnadenlos. Weder
unter XP noch ohne Debugger gestartet tritt dieses Problem auf.
Matthias
> 1. Das Programm ist für die Kommandozeile Ja und? Das ist unter Windoof aber so was von egal ... > 4. Schonmal nachgesehen was Yield() macht? Das war eine reine Win16-Geschichte. Ja, aber das Prinzip ist gleich geblieben (s. Post von faustian, da steht's wie's heutzutage gemacht werden muss).
>> 1. Das Programm ist für die Kommandozeile > > Ja und? Das ist unter Windoof aber so was von egal ... Wann wurde dieser Schwachsinn eingeführt?
zwieblum schrieb: >> 1. Das Programm ist für die Kommandozeile > > Ja und? Das ist unter Windoof aber so was von egal ... Nein.
1 | int main() { while (true) { } return 0; } |
kompilieren und auf der Kommandozeile starten... Da gibt's keine Ansage ala "Keine Rückmeldung". >> 4. Schonmal nachgesehen was Yield() macht? Das war eine reine > Win16-Geschichte. > > Ja, aber das Prinzip ist gleich geblieben (s. Post von faustian, da > steht's wie's heutzutage gemacht werden muss). Threads gibt's auch schon sehr lange...
Wenn "bla bla bla funktioniert nicht mehr" kommt, wurde vom Programm eine Exception geworfen. Normalerweise wird diese auch in der Ereignisanzeige (Systemsteuerung -> Verwaltung) als "Application Error" mit ein paar weitere Infos geloggt. "reagiert nicht mehr" kommt bei Anwendungen, die ihre Message-Loop nicht abarbeiten. Entweder weil das System zufällig generell gerade ziemlich ausgelastet ist oder (wahrscheinlicher) weil der Programmierer ne faule Sau ist und keine Lust hatte sich um das Problem z.B. in Form von Threads zu kümmern... ...kommt bei Konsolenanwendungen eigentlich eher selten vor, da diese für gewöhnlich keine Message-Loop haben (bzw. diese von Windows verwaltet wird) Wenn die Datenausführungsverhinderung (DEP) abschalten muss damit die Anwendung läuft kann man sich eigentlich sicher sein dass diese irgendwelche Ferkeleien macht. Microsoft hat auch noch nen Debugger zum Download, welcher da evtl. nützlich sein könnte: http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.