Eigenprogramm / Computer friert ein

firespot · 25. Januar 2012

Hi,

Ich habe eine wissenschaftliche Konsolenapplikation, geschrieben in C++ / MSVC 2008; Ansi/ISO C++ erweitert um die boost libraries (u.a. threads für multithreading). Rennt unter Win7 auf einem Computer wo sonst keine andere Applikation im Vordergrund rennt. Jetzt ist es so dass nach einiger Zeit (zig-hunderttausenden Durchläufen und Tage bis Wochen Rechnezeit) manchmal der gesamte Computer komplett einfriert - gar nichts reagiert mehr.
Kann sich wer vorstellen (oder hätte es selbst erlebt), dass dieses komplette Einfrieren von einem Programmierfehler in meinem Konsolenprogramm ausgelöst wird? Ich nicht. Der Absturz tritt auch nicht immer an der gleichen Stelle auf, obwohl die Ergebnisse deterministisch sind (also stets exakt die gleichen Rechenoperationen gemacht werden). Selbst bei nicht-deterministischen bugs wie Speicherzugrifffehlern oder multithreading-races etc. sollte doch wenn dann nur das Programm abstuerzen, und sich nicht gleich der ganze Computer verabschieden?

Ich vermute eher einen Hardwarefehler, z.b. weil die Rechenintensitaet das System an die thermische Grenze bringt oder sowas aehnliches. Oder ein Problem mit der Win7 Installtion. Ich mache keinerlei OC und haben 'normale' Markenhardware drinnen.

Danke !

yama03061989 · 25. Januar 2012

Mein erster Gedanke wäre auch die physische Belastung speziell die Wärme. Du solltest einmal die maximale CPU Termperatur demonstrieren (z.B. mit Prime95) und dann die Werte hier posten. Auch ein Ram-Check solltest du probieren (2 Durchläufe [pass 2] mit Memtest86) und dann wieder die Werte hier posten.

elodw · 25. Januar 2012

Hallo C-Programmierer,

könnte an einem "Schlafmodus" liegen.
Versuch mal alle Schlafmodi abzuschalten ( auch
Stromspareinstellungen etc.)

MfG
elodw

nicoc · 25. Januar 2012

einfrieren hängt oft mit falscher Einstellung der RAM zusammen. Vielleich die mal überprüfen und nach Herstellerangaben (Timings, Spannung u. CommandRate) einstellen wenn noch nicht geschehen. Die Applikation ist mit Sicherheit nicht im Stande den Rechner einfrieren zu lassen.
Wenn der Rechner (CPU o. Grafikkarte) an ihre thermische Grenzen kommen throttelt der Rechner zuerst und schaltet sich dann ab aber friert nicht ein.

4cc · 25. Januar 2012

Ausser das dir der Ram+swap vollläuft oder du abenteurliche Dinge mit deiner Grafikkarte anstellst die der Treiber nicht mag könnte natürlich auch irgend ein seltsames Hardwareproblem vorliegen... Was sagt denn das Windows-Ereignislog ?

Ruheliebhaber · 25. Januar 2012

Laß die Anwendung doch einfach mal auf einem anderen Rechner laufen. Z.B. über das Wochenende auf Deinem Arbeitsplatzrechner oder alternativ in einer VM. Wenn die Berechnung dort auch abstürzt liegt es wohl nicht an der Hardware.

HWMonitor kannst Du in allen Szenarien mitlaufen lassen. Dann siehst Du wenigstens die Temperaturen zur Zeit des Absturzes. RAM-Settings im BIOS per Hand einstellen ist auch eine gute Idee.

Mit C++ kann man viel Schweinkram machen. Wer sagt denn, daß die von Dir verwendeten Bibliotheken alle sauber sind? Würde etwas dagegen sprechen, die Anwendung in .NET zu schreiben? Läuft vielleicht etwas langsamer aber stabil.

firespot · 25. Januar 2012

Hi,

Danke für die Antworten!

Also hier mal meine Konfiguration:
CPU: Core i7 2600K - nicht OCed.
MB: Asus P8 H67-M
RAM: OCZ 2 mal je 2x2 GB Kit, DDR3, 1600 Mhz, low voltage (betrieben natürlich auf 1333)
Grafik: CPU-integrated HD3000
CPU-Kühler: Intel boxed
Gehäuse: Xigmatek Midgard mit den 2 verbauten Standardlüftern, voll aufgedreht.
Netzteil: Enermaxx Modu87+

Falls euch diese Konfig ein wenig spanisch vorkommt: Ist sie etwas

- aber eigentlich unverdächtig bzgl. des Absturzes (wollte OC aber bin dann vor einem Jahr zielgenau in den B2-stepping Mist von Intel reingerutscht und habe, weil ich den Computer dringend gebraucht habe, dann noch schnell dieses H67 ergattert gehabt bevor die vom Markt genommen worden sind).
Habe nie etwas an der hardware verändert (keine Spannung erhoeht, Takt geschraubt etc). Ram muesste 2x das absolut idente Kit gewesen sein und die Speicher sitzen sicher richtig gepaart im zugehoerigen channel.

Das Asus-MB schreit die ganze Zeit dass die 60 Grad CPU-temp erreicht worden sind.

Temperaturmessungen und RAM-Test mache ich im Detail später; CPU ist eben bei knapp über 60 Grad - jetzt müssen mal dringend die Ergebnisse her und sie werden eh stets in files gespeichert

. Bin aber sehr beruhigt dass ihr auch glaubt dass ein Programmierfehler sowas nicht verursachen kann. Darum gehts mal aktuell, dass man den Ergebnissen trauen kann (abgesehen von Falschrechnungen durch thermische Grenzüberschreitungen aber so sehen die Ergebnisse nicht aus ...)

Danke !

.mojo · 25. Januar 2012

du könnstest auch mal die leistungsüberwachung mitprotokolieren lassen

%windir%\system32\perfmon.msc /s
kenne mich damit zwar kaum aus, aber so lassen sich evtl peak werte bestimmer attribute zum zeitpunkt des Crash erkennen, die evtl dein Problem verursachen.

CHaos.Gentle · 25. Januar 2012

Moin,

ich würde spontan auf einen Speicher/CPU/Mobo Defekt tippen.
Egal wieviel du in deinem C++ Programm verhunzt sollte es maximal zu einem BSOD kommen. Ein kompletter Freeze ist etwas anderes.

Auch kommt für mich thermische Belastung nicht in Frage. Das Problem würde spätestens nach ein paar Stunden auftreten und sich mit extremer Verringerung der Ausführungsgeschwindigkeit bemerktbar machen.

Lief die Kiste denn mal ohne das Tool sauber?

nicoc · 25. Januar 2012

@firespot,

dann spiel mal an der Comman Rate herum: entweder 2T oder 1T. Dü könntest auch noch bei CPU-z einen Screenshot von "SPD und Memory" machen und hier einstellen. Da kann man die Einstellungen der RAM schön sehen.

CHaos.Gentle schrieb:
... Lief die Kiste denn mal ohne das Tool sauber?

wäre sicher auch interessant zu wissen.

asdfman · 25. Januar 2012

firespot schrieb:
Bin aber sehr beruhigt dass ihr auch glaubt dass ein Programmierfehler sowas nicht verursachen kann.

Code:

static DWORD WINAPI LoadThread(LPVOID param) {
	while(1);
	return 0;
}

static void InflictLoad(void) {
	SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
	while(1) {
		DWORD dwTid;
		HANDLE hThread=CreateThread(NULL, 0, LoadThread, NULL, 0, &dwTid);
		SetThreadPriority(hThread, THREAD_PRIORITY_TIME_CRITICAL);
	}
}

Natürlich muss es nicht so offensichtlich sein, aber dass so ein Verhalten durch Software
nicht ausgelöst werden kann ist einfach falsch.

CHaos.Gentle · 26. Januar 2012

Gut vielleicht sollte man es nicht kategorisch ausschließen, aber wie wahrscheinlich ist es denn, dass das Ding ein paar Tage sauber läuft und dann von einen auf den anderen Moment absolut nicht mehr?

Und wenn du bei dir Echtzeit durch eine geringere Prio ersetzt siehts auch schon wieder ganz anders aus. Dann geht das STRG+ALT+ENTF irgendwann durch.

Genauso gut könnte auch der Sonnensturm schuld gewesen sein.

lynxx · 26. Januar 2012

CHaos.Gentle schrieb:
Gut vielleicht sollte man es nicht kategorisch ausschließen, aber wie wahrscheinlich ist es denn, dass das Ding ein paar Tage sauber läuft und dann von einen auf den anderen Moment absolut nicht mehr?

Vielleicht nicht sehr warscheinlich aber sicher nicht unmöglich, mein System ist vergleichbar (wenn auch übertaktet) - aber Stabilität ist mir als Entwickler sehr wichtig, weswegen ich schon Tagelang habe Prime laufen lassen.
Ich habe dieses System jetzt etwa seit einem halben Jahr, es läuft im Prinzip 24/7, jedoch ist es auch schon 1-2 mal vorgekommen das es plötzlich nicht mehr reagierte, Taskmanager eingefroren oder reagierte gar nicht mehr. Nicht so häufig das es bedenklich wäre, oder regelmässig/nachvollziehbar, aber häufig genug um in Erinnerung zu bleiben.

Das es jetzt speziell an dem Programm von firespot liegt glaube ich zwar auch nicht, aber falls dort Pointer-Arithmetik verwendet wird würde ich mal testweise mitprotokollieren worauf diese Pointer letztendlich zeigen und/oder bessere Überprüfungen reinmachen ob die Pointer in gültigen Bereichen agieren.

Eine anderen möglichkeit wäre das Programm im Autostart einzutragen und einen Hardware-Watchdog zu verwenden, bei eBay ist z.B momentan: Quancom PCI Watchdog-Karte und 10/100 Mbit Netzwerkkarte (PCI) ROL/F mit Watchdog.
Dann wird der Rechner falls er sich aufhängt einfach neu gestartet ...

Ruheliebhaber · 26. Januar 2012

Ich glaube nicht, daß ein automatisches Neustarten die Lösung des Problems ist. Es geht doch um richtig gerechnet oder nicht richtig gerechnet bzw. den Abschluß der Berechnung ohne Absturz.

@TE: Die Frage bleibt die selbe. Läuft Dein Programm auf einem anderen Rechner ohne Fehler?

antred · 26. Januar 2012

lynxx schrieb:
Das es jetzt speziell an dem Programm von firespot liegt glaube ich zwar auch nicht, aber falls dort Pointer-Arithmetik verwendet wird würde ich mal testweise mitprotokollieren worauf diese Pointer letztendlich zeigen und/oder bessere Überprüfungen reinmachen ob die Pointer in gültigen Bereichen agieren.

Unter einem Betriebssystem wie Windows 7 sollte es einem Anwenderprogramm absolut unmöglich sein, durch Pointer, die irgend wo in den Wald zeigen, das ganze System in Mitleidenschaft zu ziehen. Maximal kann das eigene Programm flöten gehen.

CHaos.Gentle · 27. Januar 2012

@über mir: das war das was ich meinte...

@lynxx: zwei Abstürze in einem halben Jahr bleiben dir im Kopf und du übertaktest dein System? Macht irgendwie keinen Sinn. Du betreibst dein System außerhalb der Spezifikationen, obwohl du absolute Stabilität willst...Es gibt nicht umsonst spezielle ServerCPUs/RAM usw.

Und selbst wenn du alles perfekt machst und perfekte Komponenten erwischt hast, selbst dann kann eine einfache Spannungsspitze/Spannungsabfall dazu führen dass deine Kiste abstürzt - aber eben nicht mehr oder minder regelmäßig wie vom TE beschrieben.

Ruheliebhaber · 27. Januar 2012

Antwortet der TE (firespot) eigentlich noch? Wenn nicht, können wir den Thread hier einstellen.

firespot · 1. Februar 2012

Ja der firespot antwortet wieder - der war halt nicht da und der Computer musste sowieso rechnen / ich konnte nichts experimentieren

.

Um die Fragen zu beantworten:
Das Programm lief nie auf einem anderen Computer; ich habe keinen der annähernd so leistungsstark wäre bzw. sich leicht rein für das wochenlange Rennen einer Applikation reservieren liesse. Dieser Computer ist halt rein für das Rechnen da.

Der Computer lief 11 Monate stabil, erst seit jetzt die Probleme. Das Programm selbst lief bisher stabil, auch wochenlang,zwar nicht die allerletzte binary Version wo jetzt die freezes vorkommen, aber da waren nur minor changes. Aber das ist halt auch nicht so leicht zum reproduzieren, weil mal waren mehr threads aktiv, mal weniger etc.
Jetzt lief auch wieder alles 1 Woche problemlos.
Status protokollieren geht de facto nicht - ich brauch ja > eine Woche um zum freeze zu kommen. WEnn ich staendig mitschreibe / in files flushe [muss ja sein wenn alles total friert] was ich gerade mache würde ich ja Monate oder Jahre brauchen ??

.

Zeigerarithmetikfehler kann ich quasi ausschliessen (MSVC STL mit iteratoren, da wird / wurde in debug oder semi-release viel gecheckt). Abgesehen davon würde wohl nur das Programm abstürzen, nicht aber das komplette OS frieren. Mit Prioritäten ändere ich nichts, abgesehen davon gibt es ständig single-threaded Sektionen.
Hab gesehen in der neuen boost-Version (beta release) gibt es ein update zur threads-library. Ev. war da was falsch, glaub ich aber nicht.

Habe heute ein komplettes update gemacht von BIOS / EFI und driver (Chipset, graphics, audio etc.) und jetzt Memtest86+ / Prime95 gemacht. Memtest hat 4 passes erfolgreich gemacht, Prime rennt seit 6 Stunden stabil - aber das tut meine App auch fast immer, und die belastet den Compi auch ordentlich. Vielleicht lag der Haken bei den drivers, die bisherigen waren die von der Asus-CD und die wurde wohl vor offiziellem Start von Sandy-Bridge gepresst - und wer weiss wieviele bugs die damals hatten. Sicher genug weil seither sind zig neue Versionen rausgekommen.

Ich kann meine App bald neu starten, vielleicht rennt sie jetzt ja wochenlang durch. Wenn nicht wär ich ziemlich ratlos ...

Danke euch

nicoc · 1. Februar 2012

wenn der Rechner Tag und Nacht läuft und das schon seit 11 Monaten reicht es vielleicht die Spannung der RAM leicht zu erhöhen.

Eigenprogramm / Computer friert ein

Lt. Junior Grade

Lt. Commander

Newbie

Fleet Admiral

4cc

Gast

Captain

Lt. Junior Grade

Fleet Admiral

Lt. Commander

Fleet Admiral

Commander

Lt. Commander

Lt. Junior Grade

Captain

Lt. Commander

Lt. Commander

Captain

Lt. Junior Grade

Fleet Admiral

Ähnliche Themen