Programm stürzt mit Fehlermeldung "Speicherzugriffsfehler (Speicherabzug geschrieben)" ab

[Ivo -. (Gast)]

Hallo,
ich bin gerade dabei, ein Programm zu schreiben, dass TicTacToe einmal 
komplett durchrechnet, es ist noch nicht ganz fertig, da wollte ich es 
mal testen und da kam dann bei der Programmausführung diese 
Fehlermeldung:
Speicherzugriffsfehler (Speicherabzug geschrieben)

Googeln hat mir bisher auch nicht viel gebracht.

Falls ihr noch Fragen zum Code habt, stellt sie gerne, ich bin leider 
nicht der geborene Code-Kommentator:-)

Schon mal Danke im Voraus,
Ivo

PS: Ich nutze Linux Mint und habe mit dem G++ folgendermaßen kompiliert:
g++ main.cpp -o main.out

PSPS: Bitte diskutiert nicht über den Sinn, bzw. Unsinn des Programms 
und dass ich keine Makefiles nutze, etc. (Gut, ich hätte vielleicht noch 
die Warnungen aktivieren sollen)

[Jim M. (turboj)]

Stack overflow weil berechnen() sich selbst undendlich oft aufruft.

Kann sein dass das der Debugger nicht ordentlich anzeigt, ansonsten 
suchst Du "backtrace".

[ui (Gast)]

Hilfe zur Selbsthife ist hier angesagt.
Aktiviere erstmal -wall -werror -wpedenatic , und arbeite alle Fehler 
weg.

Noch etwas:
Du hast 4 geschachtelte for Schleifen + Rekursion? Mutig das du das 
überblickst...

[Niklas G. (erlkoenig)]

Kompiliere mit "-g" und benutze einen Debugger wie GDB. Der zeigt dir 
bessere Informationen an. Im konkreten Fall hast du eine endlose 
Rekursion gebaut, das stürzt daher mit einem Stack Overflow ab. Bei der 
Entwicklung sollte man grundsätzlich mit "-Wall -Wextra -Werror" 
kompilieren um möglichst viele potentielle Fehler zu finden, aber das 
hilft im konkreten Fall nicht.

#define leer 0
#define kreis 1
#define kreuz 2

#define breite 3
#define hoehe 3

Das ist C-Stil. In C++ sollte man hier unbedingt richtige Konstanten 
benutzen:

static constexpr short leer = 0;
static constexpr short kreis = 1;
static constexpr short kreis = 2;

static constexpr short breite = 3;
static constexpr short hoehe = 3;

Warum überhaupt überall "short"? Für das Feld wäre doch ein "enum" 
passender. Für die Größe und die Laufvariablen ein std::size_t. Für 
"zuege" müsstest du das erreichbare Maximum vorberechnen und einen 
passenden Typ wählen.

Dir ist klar dass zwischenSpeicher ständig überschrieben wird?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

ui schrieb:
> pedenatic
Meintest du "pedantic", im Deutschen "pedantisch, kleinlich"?

[Ivo -. (Gast)]

Hallo,
danke schonmal für eure Tipps, der C-Style hängt bei mir immer noch 
drin, naja...
Dass sich berechnen() immer wieder aufruft, hatte ich übersehen, dachte 
die for-Schleifen enden ja irgendwann.
Das mit dem Überschreiben von zwischenSpeicher, darüber muss ich nochmal 
nachdenken, ich sage es euch dann, wenn ich es raushabe, ob das so 
richtig ist oder nicht.

Die Fehlermeldungen-Flags kennt der Compiler angeblich nicht, er sagt 
mir:
g++ TicTacToe.cpp -o main.out -wall -werror -wpedenatic
g++: error: unrecognized command line option ‘-wall’
g++: error: unrecognized command line option ‘-werror’
g++: error: unrecognized command line option ‘-wpedenatic’

Bin ich sehr doof? (So langsam glaube ich nämlich schon ;-))

Danke für eure Geduld,
Ivo

PS: Die Variable zuege war dafür gedacht, zu wissen, wie viele Züge 
schon gezogen wurden, also ob er jetzt einen Kreis oder ein Kreuz setzen 
muss.

[Ivo -. (Gast)]

Ah, jetzt kennt er die Flags, hatte die ja klein geschrieben...

[M.K. B. (mkbit)]

Ich hab mal meine Version der Datei angehängt und wie ich das ganze in 
C++ schreiben würde. Bei Fragen, gerne schreiben.
Das Problem mit der Endlosrekursion besteht natürlich immer noch.

Durch meine Anpassungen ändert sich an der Funktion nichts, aber das 
manuelle kopieren der Felder fällt weg. Außerdem verwende ich statt der 
Magic Numbers ein Enum.

[Ivo -. (Gast)]

Hallo,
Supergroßes Dankeschön, so viel Mühe hätte ich mir nicht gemacht, 
wirklich toll von dir!!! Werde ich mich dann mal nach dem Abendessen 
noch mal dransetzen, wirklich vielen Dank!!!

[Ivo -. (Gast)]

Oh man, abschreiben müsste man können!
Ich habe doch tatsächlich von meinem "Programm-Storyboard" falsch 
abgeschrieben, der berechnungs-Funktionsaufruf darf nur passieren, wenn 
das Feld ungleich null ist, die endlose Rekursion wäre also behoben, 
ich kann es jetzt gerade leider nicht ausprobieren, da ich gerade nur 
von meinem Smartphone aus schreiben kann, werde es dann morgen nochmal 
probieren und berichten.

Ivo

PS: Was ist denn eure bevorzugte GUI für den GDB?

[Niklas G. (erlkoenig)]

Ivo Z. schrieb:
> PS: Was ist denn eure bevorzugte GUI für den GDB?

Eclipse, das hat gleich noch viele andere praktische Dinge wie 
automatisches Erstellen von makefiles, Git-Anbindung, Auto Completion & 
Highlighting, funktioniert plattformübergreifend.

[Daniel A. (daniel-a)]

Für sowas nutze ich gerne asan:

daniel@colibri:~/projects/test$ g++ -g -Og -ftest-coverage -static-libasan -fsanitize=undefined -fsanitize=address -fstack-protector-all test.c -o test
daniel@colibri:~/projects/test$ ./test 
ASAN:DEADLYSIGNAL
=================================================================
==14446==ERROR: AddressSanitizer: stack-overflow on address 0x7ffe7daf0ff8 (pc 0x55ab20b4fbdb bp 0x000000000000 sp 0x7ffe7daf1000 T0)
    #0 0x55ab20b4fbda in berechnen() /home/daniel/projects/test/test.c:26
    #1 0x55ab20b4fffa in berechnen() /home/daniel/projects/test/test.c:45
    #2 0x55ab20b4fffa in berechnen() /home/daniel/projects/test/test.c:45

(geht noch ne weile so weiter)

    #250 0x55ab20b4fffa in berechnen() /home/daniel/projects/test/test.c:45
    #251 0x55ab20b4fffa in berechnen() /home/daniel/projects/test/test.c:45

SUMMARY: AddressSanitizer: stack-overflow /home/daniel/projects/test/test.c:26 in berechnen()
==14446==ABORTING

Das ist unglaublich praktisch und funktioniert noch bei vielen ähnlichen 
Problemen. Ich lasse meine Makefiles häufig noch Debug versionen und 
Tests mit dem address sanitizer und co. bauen. (Bei Tests nutze ich auch 
noch "-fprofile-arcs" für die coverage anzeige).

[Rolf M. (rmagnus)]

Alternativ bietet sich auch immer valgrind für sowas an.

$ valgrind ./TicTacToe 
==25347== Memcheck, a memory error detector
==25347== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==25347== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==25347== Command: ./TicTacToe
==25347== 
==25347== Stack overflow in thread #1: can't grow stack to 0xffe801000
==25347== 
==25347== Process terminating with default action of signal 11 (SIGSEGV)
==25347==  Access not within mapped region at address 0xFFE801FF8
==25347== Stack overflow in thread #1: can't grow stack to 0xffe801000
==25347==    at 0x108A46: berechnen() (TicTacToe.cpp:45)
==25347==  If you believe this happened as a result of a stack
==25347==  overflow in your program's main thread (unlikely but
==25347==  possible), you can try to increase the size of the
==25347==  main thread stack using the --main-stacksize= flag.
==25347==  The main thread stack size used in this run was 8388608.
==25347== Stack overflow in thread #1: can't grow stack to 0xffe801000
==25347== 
==25347== Process terminating with default action of signal 11 (SIGSEGV)
==25347==  Access not within mapped region at address 0xFFE801FF0
==25347== Stack overflow in thread #1: can't grow stack to 0xffe801000
==25347==    at 0x4A286B0: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-amd64-linux.so)
==25347==  If you believe this happened as a result of a stack
==25347==  overflow in your program's main thread (unlikely but
==25347==  possible), you can try to increase the size of the
==25347==  main thread stack using the --main-stacksize= flag.
==25347==  The main thread stack size used in this run was 8388608.
==25347== 
==25347== HEAP SUMMARY:
==25347==     in use at exit: 72,704 bytes in 1 blocks
==25347==   total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated
==25347== 
==25347== LEAK SUMMARY:
==25347==    definitely lost: 0 bytes in 0 blocks
==25347==    indirectly lost: 0 bytes in 0 blocks
==25347==      possibly lost: 0 bytes in 0 blocks
==25347==    still reachable: 72,704 bytes in 1 blocks
==25347==         suppressed: 0 bytes in 0 blocks
==25347== Rerun with --leak-check=full to see details of leaked memory
==25347== 
==25347== For counts of detected and suppressed errors, rerun with: -v
==25347== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Speicherzugriffsfehler (Speicherabzug geschrieben)

[tictactoe (Gast)]

Ivo Z. schrieb:
> PS: Was ist denn eure bevorzugte GUI für den GDB?

KDbg natürlich: http://www.kdbg.org/

[Hulk (Gast)]

Valgrind, gibt es klickbar für Eclipse.

-Wall usw. bitte aktivieren. -O2 kann auch nicht schaden.

[Ivo -. (Gast)]

Hallo,
ich habe es jetzt geschafft, als GUI habe ich Nimever benutzt, die 
endlose Rekursion ist weg, jetzt muss ich noch ein paar Sachen 
hinzufügen, beispielsweise für Berechnungen, die nur bis Zug x gehen 
sollen.

Ivo

PS: Großes Dankeschön an alle!!!