C/C++ Forum :: simulation eines langsamen rechners

mael15 Mitglied 17:36:28 02.02.2012 Titel:

hallo,

ich habe das problem, dass mein c++ programm auf meinem entwicklungsrechner stabiler läuft als auf einem anwendungsrechner. es ist zu umständlich, mein programm häufig auf dem anwendungsrechner neu zu installieren um verbesserungen zu testen.
kann ich irgendwie auf dem entwicklungsrechner die leistung des anwendungsrechners simulieren? am optimalsten wäre eine drosselung nur für mein programm zum debuggen.

entwicklungsrechner:
i7-2760QM @ 2,4GHz
16GB RAM
Win7 Enterprise

anwendungsrechner:
core2duo @ 2,0 GHz
2GB RAM
WinXP Professional

Danke!

_matze Mitglied 17:39:26 02.02.2012 Titel:

Wäre es nicht sinnvoller zu schauen, warum das Programm "instabil" und scheinbar abhängig von der Leistung des Rechners ist? Vielleicht liegt es ja auch gar nicht an der Leistung (ist bislang nur eine Vermutung, oder?). Ich würde mal eine ausgiebige Remote Debugging Session empfehlen. Vielleicht kannst du den Fehler ja lokalisieren und dafür sorgen, dass dein Programm stabil ist, unabhängig vom verwendeten Rechner.

mael15 Mitglied 17:42:43 02.02.2012 Titel:

ja, danke, remote debugging ist natürlich eine option. ich wäre aber gerne unabhängig vom anwendungsrechner, da ich öfter mal unterwegs programmiere bzw an unterschiedlichen standorten.

SeppJ Moderator 17:55:45 02.02.2012 Titel:

mael15 schrieb:

ich wäre aber gerne unabhängig vom anwendungsrechner, da ich öfter mal unterwegs programmiere bzw an unterschiedlichen standorten.

Gerade deswegen, wäre es doch angebracht, ein fehlerfreies Programm zu haben. Dein Fehler klingt von der Beschreibung her nach einer Racing Condition. Das ist nie richtig, du hast auf deinem Entwicklungsrechner bloß Glück.

mael15 Mitglied 18:29:32 02.02.2012 Titel:

ich denke auch, dass es eine racing condition ist. ich versuche auch schon mit mutexes und critical sections entgegen zu steuern, nur kann ich eben auf dem entwicklungsrechner schlecht feststellen, ob ich das problem behoben habe, weil das programm dort nicht abstürzt. deswegen brauche ich ja die drosselung der leistung, damit abstürze auftreten wenn das problem immer noch nicht behoben ist.

also scheint es keine brauchbare möglichkeit zu geben, die leistung des entwicklungsrechners der des anwendungsrechners anzupassen?

Unregistrierter

Sicher, das es an der Geschwindigkeit liegt?
Es kann auch an mangelnden Resourcen liegen.

Mach doch eine Virtuelle Maschine.

pyhax Mitglied 18:44:17 02.02.2012 Titel:

Um was für ein Programm handelt es sich denn?

Marc++us Administrator 10:14:11 03.02.2012 Titel:

Würde ich auch sagen: virtuelle Maschine aufsetzen. Die kannst Du ja beliebig runterdrosseln...

Btw: das ist ein altes Lied schon seit Uhrzeiten... die Entwickler haben immer Powermaschinen und bemerken nie, was der Anwender für ein Leid zu tragen hat auf seinem System. Am besten auch noch 1GBit-Anbindung an den Server. Und der Anwender mit seiner GPRS-Verbindung wundert sich dann über die lahme Reaktion seines Programms...

muemmel Mitglied 11:08:15 03.02.2012 Titel:

Hi,

ich hab für die Anwendungen die ich an die Nutzer Rausgebe noch einen steinalten Laptop mit Win-XP und 64 MByte Hauptspeicher (nicht verlesen, wirklich 64 MB) und erst wenn ein Programm auch darauf noch läuft gebe ich es raus.
Man glaubt gar nicht, wie viele noch mit solchen alten Möhren arbeiten. Da ist es gut, noch so ne Kiste da zu haben um das vorher zu testen.

Gruß Mümmel

mael15 Mitglied 12:05:51 03.02.2012 Titel:

danke für eure vielen anregungen!

DirkB schrieb:

Sicher, das es an der Geschwindigkeit liegt?
Es kann auch an mangelnden Resourcen liegen.
Mach doch eine Virtuelle Maschine.

mangelnde resourcen würden auch infrage kommen, eine virtuelle maschine werden ich mal versuchen.

pyhax schrieb:

Um was für ein Programm handelt es sich denn?

das programm sammelt daten über einen a/d wandler von national instruments, speichert sie in einem buffer und stellt sie dann auf dem bildschirm dar. da das mit unterschiedlichen threads läuft könnte es dabei zu einer race condition kommen, ich prüfe das gerade.

muemmel schrieb:

Man glaubt gar nicht, wie viele noch mit solchen alten Möhren arbeiten. Da ist es gut, noch so ne Kiste da zu haben um das vorher zu testen.

die problematik war mir bisher neu, weil ich nur zum firmeninternen einsatz programmiere und auch die einsatzrechner alle kenne. aber irgendwann soll mein programm auch in die weite welt, dafür werde ich wohl in zukunft auch immer auf minimalen rechnern testen.

danke!

rapso Moderator 16:06:31 03.02.2012 Titel:

ich erstelle dazu ein paar threads die nur loopen, alle threads (sammt main thread) werden per thread affinity mask an einen core gebunden und dann laeuft dieses eine program langsam.

Dobi Mitglied 16:17:09 03.02.2012 Titel:

Falls du auch mit künstlicher Bremse bei dir nix findest, kannst du dein Programm vielleicht dazu bringen, einen core dump auf die Platte zu schreiben wenn es abkachelt. Den kannst du dir dann gemütlich bei dir im Debugger angucken. Wenn der call stack vernünftig aussehen soll, reduzierst du das Optimierungslevel in der Hoffnung, dass es dann trotzdem noch knallt.

Bitte ein Bit Mitglied 17:06:53 03.02.2012 Titel:

Du kannst ja auch mal den ApplicationVerifier ausprobieren. Der kann soweit wie ich weis eine Low Resource Simulation machen und dabei gleichzeitig auf Fehler (Locks, ...) prüfen.

mael15 Mitglied 17:16:38 03.02.2012 Titel:

Bitte ein Bit schrieb:

Du kannst ja auch mal den ApplicationVerifier ausprobieren. Der kann soweit wie ich weis eine Low Resource Simulation machen und dabei gleichzeitig auf Fehler (Locks, ...) prüfen.

gute idee! leider startet mein programm dann garnicht mehr und beim debuggen wird keine stelle meines quellcodes ausgegeben.

Dobi schrieb:

Falls du auch mit künstlicher Bremse bei dir nix findest, kannst du dein Programm vielleicht dazu bringen, einen core dump auf die Platte zu schreiben wenn es abkachelt. Den kannst du dir dann gemütlich bei dir im Debugger angucken. Wenn der call stack vernünftig aussehen soll, reduzierst du das Optimierungslevel in der Hoffnung, dass es dann trotzdem noch knallt.

ich kann dir leider nicht ganz folgen. schnelles googeln hat mich auch nciht weiter gebracht. hast du einen link, damit ich mich darin einlesen kann?

Bitte ein Bit Mitglied 18:27:09 03.02.2012 Titel:

Dranbleiben !

Konfiguriere den Application Verifier mal nur mit den Standardeinstellungen und überprüfe damit deine Debug-Version. Starte dein Program aus der IDE (hoffentlich VS) heraus. Sollte nun irgentein Absturz erfolgen, wird die IDE direkt an die Stelle springen, bloß du musst dazu nur den richtigen Thread finden, denn offenbar laufen gerne andere Threads in einem Program, ohne das man diese selbst programmiert hätte.

mael15 Mitglied 18:37:47 03.02.2012 Titel:

yo, ich programmiere mit vsPro.
wenn ich auch noch alle basic test ausschalte, dann startet das programm tatsächlich. nur ist der output leider bei jedem crash ein anderer.

ich verstehe nicht, was du damit meinst:

Bitte ein Bit schrieb:

bloß du musst dazu nur den richtigen Thread finden

alternativ bin ich noch gerade dabei, virtual pc für mein programm einzurichten. dort kann ich dann zumindest die größe des RAM einstellen. kann ich im application verifier noch finetunen, was mit "low resource simulation" genau gemeint ist?

Dobi Mitglied 18:56:59 03.02.2012 Titel:

mael15 schrieb:

Dobi schrieb:

Falls du auch mit künstlicher Bremse bei dir nix findest, kannst du dein Programm vielleicht dazu bringen, einen core dump auf die Platte zu schreiben wenn es abkachelt. Den kannst du dir dann gemütlich bei dir im Debugger angucken. Wenn der call stack vernünftig aussehen soll, reduzierst du das Optimierungslevel in der Hoffnung, dass es dann trotzdem noch knallt.

ich kann dir leider nicht ganz folgen. schnelles googeln hat mich auch nciht weiter gebracht. hast du einen link, damit ich mich darin einlesen kann?

http://www.c-plusplus.de/forum/261827
Das kannst du dir ja auch hübsch irgendwo hinpacken, damit du es in verschiedenen Programmen wiederverwenden kannst. Zum Testen schreibst du am besten etwas, das absichtlich scheppert und schaust an, ob du mit dem dadurch entstandenen dump und deinem Debugger etwas anfangen kannst. Vor zwei Wochen hab ich mit der Methode nen Bug in einem uralten (leider auch großen und chaotischen) Programm von uns gefunden, der natürlich nur beim Kunden und auch nur bei einem speziellen auftauchte. Am Ende wars dann auch ein Sync-Fehler zwischen zwei Threads, wodurch einer dann mit nem Zeiger rumhantiert hat, der irgendwo ins Nirvana schaute.

hustbaer Mitglied 19:21:47 03.02.2012 Titel:

mael15 schrieb:

Dobi schrieb:

Falls du auch mit künstlicher Bremse bei dir nix findest, kannst du dein Programm vielleicht dazu bringen, einen core dump auf die Platte zu schreiben wenn es abkachelt. Den kannst du dir dann gemütlich bei dir im Debugger angucken. Wenn der call stack vernünftig aussehen soll, reduzierst du das Optimierungslevel in der Hoffnung, dass es dann trotzdem noch knallt.

ich kann dir leider nicht ganz folgen. schnelles googeln hat mich auch nciht weiter gebracht. hast du einen link, damit ich mich darin einlesen kann?

http://www.codeproject.com/Articles/1934/Post-Mortem-Debugging-Your-Application-with-Minidu

Die dort enthaltenen Infos/Tips wie man es macht zum Debuggen die passenden .pdb Files zur Verfügung zu haben finde ich allerdings nicht gut.
Dafür gibt es Source Server/Symbol Server.

Dobi Mitglied 19:31:41 03.02.2012 Titel:

Die pdbs müssen doch nicht beim Kunden liegen. Ich hab mir die einfach zusammen mit der Exe und den Sourcen vom Zeitpunkt, an dem ich die core-dump-schreibende Version kompiliert hab, irgendwo hinkopieren und wieder ausgraben als der Dump da war. Ab da waren es dann ja nur noch drei Klicks.

mael15 Mitglied 19:39:14 03.02.2012 Titel:

danke dobi und hustbaer, die beiden links habe ich kurz überflogen und sie sehen sehr vielversprechend aus. umsetzen werde ich das auf jeden fall nächsten montag. schönes wochenende!

hustbaer Mitglied 22:09:47 03.02.2012 Titel:

Dobi schrieb:

Die pdbs müssen doch nicht beim Kunden liegen.

Hat denn jemand behauptet dass die beim Kunden liegen müssten?

Dobi Mitglied 22:15:09 03.02.2012 Titel:

Sorry, hatte gedacht, dass du das meinst, weil ich sonst nicht wüsste, was an denen stören sollte. Dann hat man die halt irgendwo rumliegen. Speicherplatz ist billig und Arbeitszeit fürs Bugsuchen teuer.

hustbaer Mitglied 22:39:25 03.02.2012 Titel:

Ja klar Speicherplatz billig und Zeit teuer.

Gerade weil die Zeit teuer ist, hab ich aber keinen Bock wenn ein Crash-Dump File dahergeflattert kommt, jedes mal manuell die passenden Kopien der Binaries und PDB Files zu suchen. Und dann noch die exakten Source Files mit denen der Spass gebaut wurde.

Also PDB Files mit Source-Server indizieren, und mitsamt den Binaries in einen Symbol-Store packen.

Dann beschränkt sich der Aufwand auf ... naja, genau nix. D.h. du machst das PDB File in Visual Studio auf, und den Rest erledigt VS.
D.h. es sucht sich erstmal die passenden PDB Files und Binaries aus dem Symbol Store, und wenn man irgendwo in den Callstack rein-doppelklickt, dann zieht sich Visual Studio noch automatisch die exakten Versionen der Source-Files aus dem jeweiligen Versionskontrollsystem.

Dobi Mitglied 22:51:11 03.02.2012 Titel:

Ja ok, so ists natürlich wesentlich eleganter. Da ich sowas zum Glück bisher nur sehr selten brauchte, war das Wegkopieren des gesamten Entwicklungs-Verzeichnis' kein Problem. Hat mir auch nur paar Sekunden Klick-Arbeit zusätzlich beschert, genau wie danach wenn die dumps reinkamen.

Unregistrierter

Du könntest auch Norton AntiVirus installieren, dann ist dein Rechner auf jeden Fall schön lahm.

Unregistrierter

..., schrieb:

Du könntest auch Norton AntiVirus installieren, dann ist dein Rechner auf jeden Fall schön lahm.

Unregistrierter

mael15 schrieb:

das programm sammelt daten über einen a/d wandler von national instruments, speichert sie in einem buffer und stellt sie dann auf dem bildschirm dar. da das mit unterschiedlichen threads läuft könnte es dabei zu einer race condition kommen

Das hört sich ja nicht gerade nach einem komplizierten Programm an. Da würde ich einfach mal mit dem Hirn debuggen empfehlen. Einfach mal überlegen, wo Threads auf gemeinsame Daten zugreifen und Schritt für Schritt im Kopf durchgehen, ob es irgendwo Konflikte gibt. Dazu sollte man natürlich wissen, was man mit gemeinsamen Daten machen darf, aber das weißt du hoffentlich, wenn du Threads verwendest. Außerdem könnte es auch noch an viel trivialeren sachen liegen, wie dass du z.B. über deinen Buffer hinaus schreibst.