simulation eines langsamen rechners
-
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.
-
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.
-
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!
-
Dobi schrieb:
Die pdbs müssen doch nicht beim Kunden liegen.
Hat denn jemand behauptet dass die beim Kunden liegen müssten?
-
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.
-
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.
-
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.
-
Du könntest auch Norton AntiVirus installieren, dann ist dein Rechner auf jeden Fall schön lahm.
-
..., schrieb:
Du könntest auch Norton AntiVirus installieren, dann ist dein Rechner auf jeden Fall schön lahm.
-
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.
