Verständnisfrage+Debuggen+Speicherugriffsfehler

Hi,
Ich habe eine Verständnisfrage.
Mein Kompiler hat mir einen Speicherzugriffsfehler zurückgemeldet.
Er war in der Form:

char a[10];
//a initialisiren
char a_ptr=a;
a_ptr+=11;
//Zugriff auf a_ptr

Um ihn zu finden bin ich mit meinem Debugger durchgegangen.
Er meldete mir den Speicherzugrifsfeherl bereits mehrere Zeilen bevor er überhaupt aufgetreten ist.
Woran liegt das??
Ist das Kompiler/Debugger abhängig, oder von der Prozessorarchitektur (Fetch/Decode/Execute) (Soweit mir bekannt darf der Prozessor bestimmte Befehle umstellen, wenn sie in einer anderen Reihenfolge ausgeführt schneller abarbeitbar, und bezüglich des Ergebnisses äquivalent sind) ??

Mein CLAGS:-Wall -ansi -O0 -march=athlon-xp -g -DVERSION=\"$(VERSION)\"
VERSION =4.3
CC =/usr/bin/g++

Gruß

drakon

Er meldete mir den Speicherzugrifsfeherl bereits mehrere Zeilen bevor er überhaupt aufgetreten ist.
Woran liegt das??

Undefiniertes Verhalten kann solches Zeugs verursachen.

Hatte ich auch schon ( VC++ ), als mir ein Fehler an einer völlig anderer Stelle angezeit wurde, als er dann wirklich war. (War Zugriff auf nicht definierten Speicher, also ganz was ähnliches, wie bei dir).

Nexus

Es kann sein, dass durch Optimierungen mehrere Anweisungen zusammengefasst werden. Eventuell wird der Zugriffsfehler dann schon bei der ersten Anweisung angezeigt, obwohl diese ihn gar nicht auslöst. So würde ich es jedenfalls erklären, aber sicher bin ich mir nicht.

AlexXXx, kannst du mal ein repräsentatives komplettes Codestück zeigen, das dieses Verhalten aufweist?

Debuggst du etwa im Release-Modus (bei MSVC++ geht das jedenfalls)?

drakon

Nexus schrieb:

Debuggst du etwa im Release-Modus (bei MSVC++ geht das jedenfalls)?

Aber nur beschränkt..

Es müssen aber nicht einmal von Optimierungen her rühren, sondern eben einfach alleine durch das, dass das folgende nicht Definiert ist den Fehler an einer völlig anderer Stelle bringen. (Auch wenn der Fehler völlig korrekt das Problem beschreibt).

Nexus

drakon schrieb:

Aber nur beschränkt..

Ja, aber gerade dort ist es bei mir auch schon vorgekommen, dass ich überhaupt nicht nachvollziehbares Verhalten erzielt habe. Deshalb mein Hinweis.

drakon schrieb:

Es müssen aber nicht einmal von Optimierungen her rühren, sondern eben einfach alleine durch das, dass das folgende nicht Definiert ist den Fehler an einer völlig anderer Stelle bringen. (Auch wenn der Fehler völlig korrekt das Problem beschreibt).

Nur weil eine Anweisung nicht definiert ist, müssen doch nicht frühere Anweisungen undefiniert sein? Zumindest scheint mir das sehr unlogisch, wenn da nicht der Compiler irgendwas zusammengefasst oder die Reihenfolge vertauscht hat.

drakon

Nexus schrieb:

drakon schrieb:

Es müssen aber nicht einmal von Optimierungen her rühren, sondern eben einfach alleine durch das, dass das folgende nicht Definiert ist den Fehler an einer völlig anderer Stelle bringen. (Auch wenn der Fehler völlig korrekt das Problem beschreibt).

Nur weil eine Anweisung nicht definiert ist, müssen doch nicht frühere Anweisungen undefiniert sein? Zumindest scheint mir das sehr unlogisch, wenn da nicht der Compiler irgendwas zusammengefasst oder die Reihenfolge vertauscht hat.

Habe ich auch nicht geglaubt, aber mir ist da im Debug Mode ein nicht erlaubter Zugriff gekommen an einer Stelle, wo gar nichts gemacht wird.. Darum habe ich da mal ein Weilchen debuggen müssen..