Richtig Debugen bei Acces Violation (Segmentaition Fault)?
-
Tja.. sehr logisch
aber gibts eine speziele technik des debugens die in so einem Fall greift?
-
fehler besser eingrenzen. z.b. breakpoints in allen funktionen setzen, die zwischen A und B aufgerufen werden, und dann von breakpoint zu breakpoint springen.
-
oder im Zweifel auch mal Zeile für Zeile laufen lassen.
(Wenn der Fehler mit Breakpoints näher eingegrenzt worden ist
(Sonst wird man Blöd, wenn man mal 20 Breakpoints nacheinander hat, ich zumindest)
-
Mit Breakpoints hab ich den "großen" Fehler gefunden und beheben können.
Jetzt hab ich aber noch einen Fehler der nur sporadisch auftritt und selbst nach ewigen debug-Sessions komm ich nicht drauf was falsch gelaufen ist.Da das problem darin liegt daß bitmaps plötzlich nicht mehr geblittet werden, und die Farben von GDI funktionen sich verändern vermute ich den Fehler in zwei Methoden.
In beiden Methoden ist ein for loop aller
for(cc=0;cc<maxModul;cc++)
und maxModul kann unter umständen 30, 40 oder auch noch größer sein.
Ebengennante Methode wird bei jeder WM_PAINT Nachricht aufgerufen.
Nach umgefähr 300 mal durch die selbe schleife debugend konnte ich den Fehler auch nicht ausmachen.Das Programm läuft ganz normal weiter nur die Bitmaps werden plötzlich nichtmehr angezeigt.
Hatt man in so einem Fall mit dem Debuger überhaupt eine Chance?
-
BackBONE schrieb:
Da das problem darin liegt daß bitmaps plötzlich nicht mehr geblittet werden, und die Farben von GDI funktionen sich verändern vermute ich den Fehler in zwei Methoden.
du hast ne GDI-ressource nicht freigegeben.
nu kann der kumpel keine mehr anlegen und macht falschfarben und falsche cursors und so.der fehler kann überall sein, wo du vergessen haben könntest, sowas freizugeben.
der einzig gute trick zum debuggen ist, keine fehler zu machen. von vorn herein mußte alles per destruktor freigeben. zur not wrapper drum bauen, die im ctor die ressource anlegen und im dtor freigeben.
-
Ich hab extra drauf geachtet alles wieder Freizugeben.
Allerdings hab ich zwei MemoryDC`s die bei CreateWindow angelegt werden,
und erst bei DestroyWindow wieder freigegeben.Ich werd jetzt mal alles so umschreiben das die MemoryDC`s auch bei WM_PAINT behandelt werden.
Wobei ich mir so eine Lösung inefizient vorstelle.ach ja... und keine Fehler zu machen is nicht ganz einfach.
Ich binn jetzt etwas länger als vier Monate am C++ programmieren und dies ist gerade mein größstes Projekt (bisher ca. 1200 Zeilen Code) Und es ist noch weit vom Ziel entfernt!
-
[quote="_BackBONE_"]Ich hab extra drauf geachtet alles wieder Freizugeben.
Allerdings hab ich zwei MemoryDC`s die bei CreateWindow angelegt werden,
und erst bei DestroyWindow wieder freigegeben.[/qoute]
zwei stück ist nicht das problem. damit kriegste windows auch nicht down. du mußt irgendwo ständig ein objekt verlieren, daß es am ende hunderte sind, damit die besagten effekte eintreten.Ich werd jetzt mal alles so umschreiben das die MemoryDC`s auch bei WM_PAINT behandelt werden.
Wobei ich mir so eine Lösung inefizient vorstelle.nee. das zeichnen selber ist sowas von lahm. da kannnste ruhig die ressourcen so lokal wie möglich allokieren und deallokieren.
ach ja... und keine Fehler zu machen is nicht ganz einfach.
Ich binn jetzt etwas länger als vier Monate am C++ programmieren und dies ist gerade mein größstes Projekt (bisher ca. 1200 Zeilen Code) Und es ist noch weit vom Ziel entfernt!tja. nach 4 monaten darfste noch nicht GUI machen. hat dir das keiner gesagt?
-
volkard schrieb:
tja. nach 4 monaten darfste noch nicht GUI machen. hat dir das keiner gesagt?
Nö.. hatt mir keiner gesagt,
Sollt ich dann wieder zurück auf DosBoxen gehn?
Mir fallen da schon ein paar sachen ein die sich ohne GUI realisieren lassen (Dateikonverter zum Beispiel).
-
BackBONE schrieb:
volkard schrieb:
tja. nach 4 monaten darfste noch nicht GUI machen. hat dir das keiner gesagt?
Nö.. hatt mir keiner gesagt,
Sollt ich dann wieder zurück auf DosBoxen gehn?
Mir fallen da schon ein paar sachen ein die sich ohne GUI realisieren lassen (Dateikonverter zum Beispiel).das wäre ideal. in der tat.
zur begründung: c++ ist ne sprache für hard-core-programmierer. c++ klappt nur, wenn du c++ total gut kannst. wenn du auch nur kleine unsicherheiten im stil hast, schießt du dir das knie weg. aber dafür ist c++ als belohnung auch wahnsinnig toll, wenn du es kannst. ich progge seit vielen jahren in c++ und ballere mir in steter regelmäßigkeit immernoch das knie weg (vorgestern war einfach nur "aua"). also geh nicht davon aus, daß du nach ein oder zwei jahren sicher bist.
du mußt "effektiv c++ programmieren" von scott meyers unbdingt lesen. da geht es um das "warum man was wie in c++ macht" statt nur um das "wie man was macht" wie in fast allen anderenn büchern. er hat auch nen prima stil drauf. er zeigt immer nen code, der toll aussieht, und du würdest nicht meinen, daß du es besser könntest. dann zeigt er, warum! das ein knieschuss ist. meistens ne schutzverletzung (unter linux ein coredump). und dann sagt er, wie man den vermeidet. und dann, wie man seinen programmierstil verändern sollte, dam man ihn in zukunft immer vermeidet.
wenn du das buch in fernleihe kriegst, isses gut. wenn du es kaufen musst, benutz den amazon-link von diesem forum, dann kriegt der betreiber ein prozent oder so vom kaufpreis.
in der win-programmierung, du benutzt MFC, sind lauter klassen. du kennst vererbung. aber weißt nicht sicher, wann man vererbung nehmen sollte? da hilt das buch des betreibers hier. sollte irgendwo oben eingeblendet sein. lies das auch. aber nach "effektiv c++ programmieren" und vielleicht auch nach der bibel ("die programmiersprache c++" von stoustrup). wenn du die MFC benutzt und nicht bei jeder zweiten methode vor abscheu die maus losläßt, dann haste c++ nict ausreichend kapiert, um die MFC zu benutzen, ohne völlig verdorben zu werden. die MFC sind grandios schlecht designed. aus heutiger sicht. damals waren sie toll. aber inzwischen hat sich die welt halt 5000-mal um sich selbst gedreht und die informatiker haben was dazugelernt.also eingesehen haste es jetzt. nur glauben tuste es nicht. nun zum gleuben. schau erstmal karate-kid oder sowas.
der junge held geht zum meister und lernt und lernt. er lernt komische sachen. auf tonkrügen hopst er herum. er wienert autos. er meditiert. nur eins macht er nicht. kämpfen. aber er wird in den grundlegenden techniken saugut. später mal, als er in der stadt für seinen meister schnaps kaufen soll, wird er von größeren und stärkeren rüpeln angegriffen. und voiá, er macht sie alle platt. mit links. warum? weil er die grundlegenden techniken einfach besser drauf hat. und so soll es dir ergehen. lerne erstmal die basics. mach mit der console wirklich so lange rum, bis du weißt, daß du sehr gut bist. zur not kannste mir ne mail schicken und fragen, wie gut du bist, dann checke ich mal, ohb du schon schnaps kaufen solltest. und wenn du dann alle konzepte von c++ kannst, dann wird das verwenden der MFC für dich
-erstens: unangenehm, weil die leute damals noch nicht so fit waren
-zweitens: ein kinderspiel, weil die deren absichten völlig klar sind (du warst ja auch mal in deren stadium, ist noch gar nicht lange her).
.
und du machst die ganzen skript-kiddies mit links platt. die ganzen game-coderz mit links und dem rechten kleinen finger.edit: volkard hat nen treiber für seine grottenalte digicam gefunden. hier bei der arbeit: http://volkard.de/queue.jpg
die kronkorken mit namen sind zeiger und die andern kronkorken bezeichnen belegten speicher.
-
Von der MFC hab ich gleich die Finger gelassen.
Meine erste Intention die DosBox zu verlassen war als ich mit Klassen angefangen hab. Ich wollte so eine Art Zustandsanzeige für bestimmte Eigenschaften haben (so ähnlich wie LED`s ,wollt ich mit verschiedenfarbigen Rectangles realisieren).
Und mit Petzold fand ich den einstieg in die API auch nicht so schwer, weil Petzold eben immer erklärt was warum pasiert.
Als ich dann die Möglichkeiten gesehn hab (kontrolle über so ziemlich alles) hatt ich dann ein Bündel Ideeen für die ich zumindest das Grundgerüßt basteln wollte.
Nachdem ich ein und dieselbe Klasse in vier verschiedenne Varianten erstellt hab
wurde das Bündel Ideeen noch größer.volkard schrieb:
du mußt "effektiv c++ programmieren" von scott meyers unbdingt lesen. da geht es um das "warum man was wie in c++ macht" statt nur um das "wie man was macht"
Mir hatt bisher "Teach Yourself C++ in 21 Days" (wobei 21 Tage mehr als zuwenig sind) und "Thinking in C++" gut weitergeholfen.
Werd mir deinen Buchtipp definitiv zulegen, is immer gut wenn man die Stolperfallen kennt bevor man drüberfällt!volkard schrieb:
zur begründung: c++ ist ne sprache für hard-core-programmierer. c++ klappt nur, wenn du c++ total gut kannst. wenn du auch nur kleine unsicherheiten im stil hast, schießt du dir das knie weg.
Ich nehm immer erst Papier und Stift überleg mir vorher was ich alles für eine "schmerzlose" Umsetzung brauch.
Manche stellen schreib ich auch als pseudocode aufs Papier.
Dann fällts mir leichter konsequent auf ein Ziel hinzuarbeiten, und Stellen die ich verhunzt hab neu aufzusetzen.volkard schrieb:
also eingesehen haste es jetzt. nur glauben tuste es nicht. nun zum gleuben. schau erstmal karate-kid oder sowas.
...linke Hand eintippen... rechte Hand compilieren
volkard schrieb:
die kronkorken mit namen sind zeiger und die andern kronkorken bezeichnen belegten speicher.
Keine schlecht Idee