C++ Speicherfehler finden

Vor allem durch erase invalidierte Iteratoren katapultieren dich direkt 
in die Hölle, wenn du in ner For-Loop weiteriterierst.

Peter II schrieb:
> Sven P. schrieb:
>> Geht es denn um MS-Müll oder ließe sich das auch mit einem gcc
>> übersetzen?
> sehr schlechte Idee, denn schon das ändern des compiler kann den fehler
> teilweise komplett verschwinden lassen oder andere auftrauchen lassen.

Ja, wenn man Visual Studio streicht kann der Fehler ziemlich schnell weg 
sein;-)

Visual Studio kann durchaus mal eine Debug Version aus versehen mit der 
Release Version Linken, dann wird jeder std::string verhauen, oft auch 
der Stack...

Wenn die Applikation aus mehreren Teilen besteht mal die Übergänge 
Debuggen, und wenn sich plötzlich die Werte ändern: Dann hast du den 
Fehler;-)

Welche Version vom VS?

> Kein tool kann erkennen wenn du innerhalb deines Speichers andere Daten
> überschreibst. Sie können maximal erkennen wenn du über ein array
> hinausschreibst und sie dort eine Guardpage angelegt haben.

Natürlich gibt es Tools die das können, es werden einfach 
Metinformationen zu den Daten hinzugefügt.
Ich glaube Valgrind kann das auch, natürlich geht sowas aber mit MS 
Visual Studio nicht.

> Ich würde den quellcode einfach noch mal genauer anschauen, es dürfte
> bei C++ doch nicht so viele stellen geben wo man mit pointern arbeitet.

@Peter II
Es gibt Leute die schreiben auch etwas grössere Applikationen als du, 
wenn du mehr als 3 Klassen verwenden, dann kann es durchaus viele 
Stellen geben bei denen ein Fehler möglich wäre.

> Sind denn auch Thread beteiligt, ist das verhalten nachvollziehbar?
> Passiert also bei den gleichen startbedingungen immer das gleiche?

Wenn Ja: Kannst du mit diesen Informationen Debuggen, dann findest du 
heraus wo das es abschmiert.

Wenn nicht: Dir bleibt wohl nichts anderes übrig als entweder ein 
entsprechendes Analysetool zu verwenden, oder du baust massenweise 
Logzeilen ein.


mfg Andreas

Peter II schrieb:
> Sven P. schrieb:
>> Guter Witz :-}
>> Und du glaubst, mit den Templates kann man sowas nicht produzieren...?
>> Es reicht schlimmstenfalls schon ein vergessenes 'virtual' aus.
> damit überschreibt man meines wissens aber nicht andere Daten, kann es
> nur passieren das man aus einen ungültigen speicherbereich daten lesen
> will. Und das zeigt der Debugger gleich an der stelle an.

Kommt darauf an. Der Debugger springt erst an wenn der Fehler schon 
längst passiert ist, und wenn da der Stack weg ist kann er dir auch 
nichts mehr anzeigen.

Der Debugger weiss dann nämlich NICHT wo die Applikation zuletzt war. 
Woher auch?

Kann bei C++ durchaus mal vorkommen...



mfg Andreas

Nur mal so am Rande gefragt: Die verschiedenen Runtime-Checks, die die 
CRT bieten kann, sind auch alle aktiviert? Die finden sich z.B. unter 
den "Code Generation"-Optionen und WIMRE auch irgendwo bei den 
Linkeroptionen. Gerade auf diesem Gebiet sind die neueren VC-Versionen 
erheblich besser geworden als das steinalte VC6.

Welche Version wird hier verwendet?

... oder ist das einfach nur ne nicht gefangene Exception? Durch Stack 
Unwinding ist da für den Debugger tatsächlich nichts mehr zu holen. 
Abhilfe: Testweise mal einen Breakpoint auf alle Exceptions setzen. Wie 
das im Visual Studio genau geht, weiß ich aber nicht.

Klaus schrieb:
> Ich programmiere an einem größeren Projekt in C++ mit MS Visual Studio.
>
> Leider gibt es gelegendlich Speicherzugriffsfehler. Das dumme an der
> Sache: Der Debugger steigt irgendwo an einem Punkt aus, nachdem schon
> alles zerschossen ist. Der Stack scheint total im Eimer zu sein, denn es
> lässt sich nichtmal ein vernünftiger Callstack anzeigen, um zu sehen,
> welche Funktion gerade ausgeführt wurde.

Auch wenn ein Tool zur statischen Codeanalyse den Fehler in Deinem 
speziellen Fall vielleicht nicht finden kann: Verwendest Du ein solches 
Tool? Wenn nein, würde ich dies tun, und die vom Tool gemeldeten Fehler 
und Warnungen einfach mal nicht ignorieren :-)

Im VS:

Debug -> Exceptions -> Win32 Exceptions -> Access Violation

einschalten. Bei einer Access Violation hält er dann da, wo sie 
auftritt, und nicht erst da, wo es crashed.

Anmerkung:
> Geht es denn um MS-Müll
Ich arbeite täglich mit dem MS VC2010, und möchte es nicht missen. Schon 
gar nicht mit irgendwelchen zusammengestückelten gnu Sachen, bei denen 
erst mal "alles zum Laufen bringen muss".

Speicherfehler und Memory Leaks muss man von Anfang an mitbeobachten und 
gleich korrigieren. Diesen Prozess rauszuzögern bringt nichts, es macht 
alles nur noch komplexer. Unittests sind hilfreich.

Bei VC++ gehört ans Anfang in jedes File gleich mal

#ifdef _DEBUG
#undef THIS_FILE
static char THIS_FILE[]=__FILE__;
#define new DEBUG_NEW
#endif

rein, damit dir die Runtime selbst hilft, derartige Problemstellen zu 
detektieren und zu finden.


Wobei man in C++ durch die konsequente Nutzung des RAII Idioms gute 
Chancen hat, diesem Problemkreis relativ leicht zu entkommen.
RAII bedeutet Resource Aquisition Is Initialization
In einer Kurzfassung auf die wesentlichste Auswirkung reduziert: Eine 
Klasse soll 1 Resource und nur 1 Resource dynamisch verwalten. Benötigt 
eine Klasse mehrere dynamische Dinge, dann wird für jedes davon eine 
eigene Klasse fällig, die sich nur um die Verwaltung dieses 1 
dynamischen Teils kümmert. Copy Konstruktoren, operator= und 
Destruktoren der zusammenfassenden Klasse werden dann sehr einfach bzw. 
können überhaupt vom Compiler generiert werden.

Auch immer bewusste machen: Welche Pointer sind 'owning-Pointer', welche 
sind 'non-owning'. Ein owning Pointer ist einer, der für die Verwaltung 
zuständig ist. Sein Job ist es, die Resource am Ende ihrer Lebensdauer 
zu zerstören. Non-owning Pointer haben dieses Recht nicht. Daraus folgt 
sofort eine mehr oder weniger Grundregel: die Klasse die eine Resource 
allokiert, ist auch dafür zuständig, sie zu zerstören. Ein anderes 
Objekt kann vielleicht einen Pointer darauf halten, aber sie hat nicht 
das Recht an der Allokierung selbst rumzupfuschen.

Die "Rule of Three" beachten:
Benötigt eine Klasse eine eigene Version der Funktionen
  * Destruktor
  * Copy Konstruktur
  * Operator =
dann ist es sehr wahrscheinlich, dass sie alle 3 benötigt. Will man Copy 
Constructor bzw. Operator= nicht implementieren, dann muss man sie 
wenigstens für den Compiler/Linker unbrauchbar machen um sich als 
Programmierer selbst vor eine unbeabsichtigten Verwendung zu schützen. 
(private deklarieren und nicht implementieren)

const-korrektes Arbeiten ist auch etwas, das einem manchmal fehlerhafte 
Verwendungen aufzeigt. Auch hier gilt: von Anfang an durchziehen. const 
im Nachhinein einziehen zieht oft Rattenschwänze an Codeänderungen nach 
sich. Die sind zwar meistens unkomplizierte Editiersession aber Zeit 
kosten sie trotzdem.

ASSERT reingeben. Assertions können manchmal Probleme aufzeigen, die 
sich noch nicht zum Desaster ausgewirkt haben. Ziel: Das Programm selber 
soll anzeigen, dass da etwas nicht stimmt. Und zwar unabhängig davon, ob 
der Aufrufer Fehlercodes auswertet oder nicht. Ein Out of Bounds Zugriff 
in ein Array ist ein Fehler! Selbst wenn eine Funktion den übergebenen 
Index prüft und im Fehlerfall die Operation mit einem Fehlercode 
abbricht, soll ein ASSERT diesen Fehler im Debugger unmissverständlich 
melden, denn er weist oft auf ein grundlegenderes Problem beim Aufrufer 
hin.

Und ganz wichtig:
Nimm das Prinzip der Datenkapselung ernst!
Eine Klasse, die Pointer auf ihre Daten rausgibt, kann schon der erste 
Sargnagel sein.


Solange die generelle Programmstruktur nicht zu verkorkst ist, kann man 
viele Dinge auch im Nachhinein noch mit einem entsprechenden Aufwand 
nachrüsten. Meistens lohnt sich das sogar, da die Analyse von 
Stack-Traces auch einiges an Aufwand bedeutet und man mit der Kentniss, 
wo welche Operation schief gelaufen ist, ja noch nicht unbedingt eine 
Abhilfe dagegen hat.

Rufus Τ. Firefly schrieb:
> Die verschiedenen Runtime-Checks, die die
> CRT bieten kann, sind auch alle aktiviert?

Präzisiert:

/RTCc (smaller type check)
/RTC1 bzw. /RTsu (stack frames, uninitialized variables)
/GS (buffer security check)

Sven P. schrieb:
> Ich bin zumindest so erfahren, dass ich mir MSVC++ nicht mehr antue und
> Windows als Entwicklungsplattform abgeschrieben habe.

Wenn die Entwickler fehlerhaften Code schreiben, ist dann der Compiler / 
die Entwicklungsumgebung / das Betriebssystem dran schuld?

Sooooooo schlecht, wie manche sie gerne hätten, sind Compiler und IDE 
von Microsoft jetzt auch wieder nicht.

Mark Brandis schrieb:
> Wenn die Entwickler fehlerhaften Code schreiben, ist dann der Compiler /
> die Entwicklungsumgebung / das Betriebssystem dran schuld?

Selbstverständlich. Wer denn sonst?

> Sooooooo schlecht, wie manche sie gerne hätten, sind Compiler und IDE
> von Microsoft jetzt auch wieder nicht.

Man könnte sogar sagen, daß das eines der wenigen tatsächlich 
brauchbaren Produkte ist, auch wenn MS sich redlich Mühe gibt, das zu 
ändern. Das Fenster- und vor allem Maushandling in VS2010 ist eine 
mittlere Katastrophe, der native Compiler und der Debugger hingegen sind 
vorzüglich, auch wenn man auf das unnötige .Net-Geraffel verzichtet.

Schön wäre es, wenn es eine von diesem Geblubber befreite reine C- und 
C++-Variante des VS2010 gäbe.

Ärgerlich und peinlich ist die nach wie vor fehlende C99-Unterstützung.

Rufus Τ. Firefly schrieb:

> ändern. Das Fenster- und vor allem Maushandling in VS2010 ist eine
> mittlere Katastrophe, der native Compiler und der Debugger hingegen sind
> vorzüglich,

Jep.
Seit sich Herb Sutter des C++ Compilers angenommen hat, hat der einen 
steilen Qualitätssprung hingelegt. Man kann MS viel vorwerfen, aber ihr 
C++ Compiler gehört sicherlich mit zu den Besten, die es gibt.

(und das .Net Geraffel nehm ich bei C++ sowieso nicht ernst. Ich träum 
ja immer noch davon, dass es irgendwann eine funktional gleichwertige 
Lib in nativ C++ gibt. Denn eines muss man schon sagen: Die .Net Lib ist 
sauber aufgebaut und ordentlich durchdesigned. Nicht so wie die MFC, zu 
deren Ehrenrettung man nur sagen kann: Anfang der 90-er Jahre war der 
C++ Compiler halt noch lange nicht soweit um ein eleganteres Design zu 
erlauben)

Rufus Τ. Firefly schrieb:
> Das Fenster- und vor allem Maushandling in VS2010 ist eine
> mittlere Katastrophe

Was stört dich denn?
ich finde es ganz gut.
Das einzige, was mich nervt, ist dass man im Gegensatz zu früher, die 
Watchfenster nicht größer machen kann, als den Ausschnitt, den man 
gerade sieht.

im VS2005 gabs dann halt einen Scrollbalken, so dass man zur Not auch 
den längsten, verschachteltsten Template-Typ lesen konnte.
Jetzt muss man erst das Fenster ausdocken.


Rufus Τ. Firefly schrieb:
> Ärgerlich und peinlich ist die nach wie vor fehlende C99-Unterstützung.
warum, der Standard ist doch noch nicht mal 12 Jahre alt ;)

Vlad Tepesch schrieb:
> Rufus Τ. Firefly schrieb:
>> Das Fenster- und vor allem Maushandling in VS2010 ist eine
>> mittlere Katastrophe
>
> Was stört dich denn?

Mich stört zb das 'Property' Fenster. Ganz besonders im Resource-Editor.
Ich fand die alten Dialoge übersichtlicher und besser in der Bedienung, 
vor allen Dingen wenn es darum ging, Handler an Controls zu binden.
Und wie ich in der MFC an einen Dialog mit dem Wizzard eine OnInitDialog 
anhängen kann hab ich auch noch nicht rausgefunden :-)

Karl Heinz Buchegger schrieb:
> Seit sich Herb Sutter des C++ Compilers angenommen hat, hat der einen
> steilen Qualitätssprung hingelegt.

Wann war das ungefähr?

> Man kann MS viel vorwerfen, aber ihr C++ Compiler gehört sicherlich
> mit zu den Besten, die es gibt.

Ist das so? Ich habe das eher so in Erinnerung:

Früher nahm man den GCC, wenn man kein Geld hatte und den MSC, wenn man
schnellen Code erzeugen wollte.

Der GCC holte aber mit den Oprimierungen stark auf, so dass man mit dem
MSC keine Geschwindigkeitsvorteile (eher Nachtteile) hatte. MSC wurde
fortan hauptsächlich deswegen verwendet, weil man Visual Studio wollte
und der MSC eben hübsch integriert mitgeliefert wurde.

Der GCC hatte zusätzlich den Vorteil, dass er sich immer stark am je-
weils gültigen Standard orientierte, was aber natürlich für Windows-
Only-Programmierer kein so starkes Argument ist. Trotzdem hat hier der
MSC inzwischen aufgeholt.

Dann kam der Intel-Compiler und hat sowohl GCC als auch MSC weggefegt,
was die optimierte Codegenerierung betrifft. Da er aber ordentlich
kostet, wird praktisch nur im professionellen Bereich und dort haupt-
sächlich im Heigh-Performance-Computing eingesetzt.

Den Intel-Compiler würde ich als den aktuell mit Abstand stärksten
Compiler für PCs ansehen, MSC und GCC folgen mit Abstand auf etwa
gleichem Niveau.

Ich verwende den MSC seit ein paar Jahren kaum noch, mag sein, dass er
in dieser Zeit wieder kräftig zugelegt hat, deswegen meine Frage von
oben bzgl. Herb Sutter.

Yalu X. schrieb:
> Karl Heinz Buchegger schrieb:
>> Seit sich Herb Sutter des C++ Compilers angenommen hat, hat der einen
>> steilen Qualitätssprung hingelegt.
>
> Wann war das ungefähr?

Das muss so ungefähr um 2004, 2005 rum gewesen sein. Nagle mich da jetzt 
aber nicht auf 2 oder 3 Jahre auf/ab fest.

>
>> Man kann MS viel vorwerfen, aber ihr C++ Compiler gehört sicherlich
>> mit zu den Besten, die es gibt.
>
> Ist das so? Ich habe das eher so in Erinnerung:

Es ist so.
MS hat enorme Anstrengungen in den Compiler gesteckt um ihn 
standardkonform zu machen.

Vlad Tepesch schrieb:
>> Das Fenster- und vor allem Maushandling in VS2010 ist eine
>> mittlere Katastrophe
>
> Was stört dich denn?

Versuch mal was mit dem Scrollrad anzufangen. Das lässt sich nur mit 
Aufwand reparieren, denn MS hat teilweise erheblichen Aufwand getrieben, 
um das Scrollrad nutzlos werden zu lassen (Beispiel: Debugfunktion 
"Attach to remote process", Auswahl des Prozesses in der Listbox. Die 
scrollt überhaupt nicht).

Glücklicherweise gibt es Tools, die das komplett kaputte 
Scrollradhandling beheben, hier insbesondere XMBC
http://www.highrez.co.uk/downloads/XMouseButtonControl.htm

Desweiteren ist das Verhalten der diversen Popupfensterchen extrem 
lästig, die sich vor den Quelltext schieben und da nur mit Gewalt 
wegzubekommen sind. Auch beeindruckend ist die hartnäckige Unfähigkeit, 
mit "goto definition" an eine Codestelle zu springen und die dann auch 
im jeweiligen Fenster anzuzeigen. Das jedenfalls tut VS2010 nicht, wenn 
man sich die Freiheit nimmt, mehrere Sourcecodefenster gleichzeitig 
sehen zu wollen (und nicht die komplett retardierte standardmäßige 
"Workbook"-Variante nutzt).

Letztlich nutze ich zum Arbeiten mit VS2010 drei Monitore, den in der 
Mitte für das eigentliche Arbeiten und die beiden rechts und links davon 
für die zig Zusatzfensterchen, die mir sonst den Blick auf den Quelltext 
versperren wollen.

Karl Heinz Buchegger schrieb:
>>> Man kann MS viel vorwerfen, aber ihr C++ Compiler gehört sicherlich
>>> mit zu den Besten, die es gibt.
>>
>> Ist das so? Ich habe das eher so in Erinnerung:
>
> Es ist so.
> MS hat enorme Anstrengungen in den Compiler gesteckt um ihn
> standardkonform zu machen.

Dass der MS-Compiler inzwischen weitgehend standardkonform ist, habe ich
noch mitbekommen und oben auch geschrieben. Aber hat er in den letzten
Jahren auch bei der Optimierung/Codegenerierung zugelegt? Mein letzter
Stand ist der, dass er dabei mit dem GCC etwa gleichauf war.

XTerminator schrieb:
>> Den Intel-Compiler würde ich als den aktuell mit Abstand stärksten
>> Compiler für PCs ansehen, MSC und GCC folgen mit Abstand auf etwa
>> gleichem Niveau.
>
> Nur für Intel-CPUs, für andere CPUs optimiert er nicht nur nicht
> richtig, sondern erzeugt sogar absichtlich pessimierte Codepfade.

Das ist natürlich zu befürchten. Vielleicht bringt ja AMD mal einen
Compiler auf den Markt :)

Rufus Τ. Firefly schrieb:
> Ärgerlich und peinlich ist die nach wie vor fehlende C99-Unterstützung.

Mal ganz ehrlich: Wer programmiert unter Windows noch in C? Das sind
doch höchstens solche, die Software für ein Fremdsystem (bspw. einen µC)
entwickeln und komplexe Module vorab auf dem PC testen wollen. Aber das
sind sicher nicht die Kunden, die MS mit dem Visual Studio ansprechen
will.

Yalu X. schrieb:
> Mal ganz ehrlich: Wer programmiert unter Windows noch in C?

Ich mach das, weil ich einige wirklich sehr alte Projekte weiterpflege. 
Da das keine GUI-Anwendungen sind, sondern Dienste bzw. andere 
Hintergrundprozesse, ist das auch nicht sonderlich schlimm.
Diese Projekte habe ich vor knapp 20 Jahren für die damals erscheinende 
erste ernstgemeinte Windows-Version angefangen zu entwickeln. Und die 
war, bereits in den ersten Beta-Versionen, ein ganz erheblicher 
Fortschritt gegenüber dem 16-Bit-DOS-Gefrickel, auch wenn die 
Oberfläche, äh, grässlich war.

Interaktive Anwendungen würde ich ums Verrecken nicht in C schreiben 
wollen -- es ist allerdings sehr lehrreich, es mal getan zu haben, weil 
erst dann man verstehen kann, warum auch so etwas wie die MFC ein 
Fortschritt sein kann.

Ich würde auch heutzutage die oben erwähnten Programme nicht mehr in C 
schreiben wollen, aber ich konnte damals schlichtweg kein C++, und die 
mir zur Verfügung stehenden C++-Compiler waren damals auch eher sehr 
lausig.

Da ich Windows als Entwicklungsplattform in absehbarer Zeit nicht 
verlassen können werde, werde ich damit leben müssen, mit Windows zu 
arbeiten.

Und ich gehöre zu den Menschen, die IDEs bevorzugen, auch wenn die auf 
jedem System wieder anders sein mögen.

Peter II schrieb:
> also das scollrad unter VS2003 geht ohne Problem

Tja, VS2003 ist auch was ganz anderes als VS2010, da waren immerhin 
zwei Versionen dazwischen. Daher sind Vergleiche sinnarm.

Peter II schrieb:
> ich habe es gerade mit VS2010 getestet - es geht dort.

Und Du hast auch exakt verstanden, welches Fenster und welche Liste 
darin ich meine?

Peter II schrieb:
> denke schon

Sieht so aus. Genau das funktioniert auf meinem System (W7x64) nicht, 
bzw. nur mit zusätzlichen Hilfsmitteln wie o.g. XMouse Button Control.
Selbst nach einem direkt in die Liste klicken scrollt das Mausrad diese 
Liste nicht. Die einzige Möglichkeit ist das "Anfassen" des 
Scrollbalkens bzw. das daraufherumklicken.

Allerdings verwende ich auch den Standardmaustreiber und nicht das 
obszön aufgeblähte Maustreiberbubufunzpaket des Mausherstellers (hier: 
Logitech).

Das Verhalten hat übrigens auch der Hersteller o.g. Maustools bestätigt 
und sein Werkzeug eigens auf diese Eigenheit angepasst.

Dieses Maustool ist sowieso erforderlich, weil das Standardverhalten von 
Windows im Umgang mit dem Scrollrad sowieso äußerst beknackt ist 
(Scrollnachrichten landen im Fenster, das den Mausfocus hat, und nicht 
in dem Fenster, über dem sich der Mauszeiger befindet).

Peter II schrieb:
> hier 32bit - aber SP1 vom Studio installiert

Vielleicht haben sie's da repariert. Zwar nutze ich das SP1 jetzt auch, 
aber auf das reparierte Scrollen will ich nicht verzichten.

Peter II schrieb:
> das doch mal bitte was ihr von dem Standard so dringend braucht, ich
> hatte zumindest noch nichts vermisst.

was ich immer extrem vermisse sind benamte Initializer für struct-member 
keine Ahnung wie das offiziell heißt, aber ich mein das:

1

struct A

2

{

3

  int i;

4

  int j;

5

};

6

7

8

9

A  a = { .i=1,  

10

         .j=2

11

       };

Diese Initialiserungen sind unter C90 eine beachtliche Fehlerquelle.

lanai schrieb:
> Peter II schrieb:
>> Rufus Τ. Firefly schrieb:
>>> Versuch mal was mit dem Scrollrad anzufangen.
>> es ging um den c99 standard - nicht um das VS
> Nö, hier existieren, wie in fast jedem Thread, mehrere Diskussionen
> parallel vor sich hin.

Wie lanai schon andeutete: Der TO stieg nach zwei Posts aus.
Warum macht ihr für solche wiederkehrenden Themen nicht einen separaten 
Thread auf? Der könnte sogar fixiert werden. Bedarf ist scheinbar 
vorhanden, wenn die Moderation hier schon hijacked.

Jean G. schrieb:
> Wie lanai schon andeutete: Der TO stieg nach zwei Posts aus.
> Warum macht ihr für solche wiederkehrenden Themen nicht einen separaten
> Thread auf? Der könnte sogar fixiert werden. Bedarf ist scheinbar
> vorhanden, wenn die Moderation hier schon hijacked.

Oder man könnte die Diskussion in einen eigenen Thread abspalten. Ich 
weiß aber nicht wie gut oder ob überhaupt die Foren-Software das 
unterstützt. Falls man mühsam von Hand jeden einzelnen Post verschieben 
müsste, dann könnte ich gut verstehen dass das keiner freiwillig machen 
will, würde mir genau so gehen.