Programmabsturz - Fehler unbekannt

[Daniel S. (dani2304)]

Hallo,
ich muss ein Sodoku Spiel programmieren, aber weiß nicht wieso mein 
Programm bei der Überprüfung der Zeilen abstürzt...

    void sodokuCheck(char **spielfeld){
    int i,j,pruef=0;
    for(j=2;j<7;j+=2)
    {
            for(i=2;i<7;i+=2){
                    pruef=0;
                    printf("%i,%i",i,j);
                if(spielfeld[i][j]!=spielfeld[i+2][j] && spielfeld[i[j]!=spielfeld[i+4][j] && spielfeld[i][j]!=spielfeld[i+6][j]&& i==2){
                    printf("Erste");
                   pruef=1;
                    goto schleife;
                }
                if(spielfeld[i][j]!=spielfeld[i+2][j] && spielfeld[i[j]!=spielfeld[i+4][j] && i==4){
                    printf("Zweite");
                    pruef=1;
                    goto schleife;
                }
                if(spielfeld[i][j]!=spielfeld[i+2][j] && i==6){
                    printf("Dritte");
                    pruef=1;
                    goto schleife;
                }
                printf("Fehler in %i, %i",j,i);
                return;
                schleife:;
        }
    }
    }

In dem Spielfeld kann man mehrere Zahlen eingeben und diese Funktion 
soll üerprüfen ob die Zahl in jeder Spalte nur einmal vorkommt. Habe 
aber keine Ahnung warum das Programm abstürzt. Habe einen ähnlichen Code 
bei der Überprüfung der Spalten und dort funktioniert es.


MfG

[Peter II (Gast)]

Daniel S. schrieb:
> aber weiß nicht wieso mein
> Programm bei der Überprüfung der Zeilen abstürzt...

wir auch nicht. Zum helfen brauchen wir mehr code.

wie groß wird spielfeld angelegt?

[Peter II (Gast)]

Nachtrag:

das goto ist böse - verwende continue in der schleife, dann brauchst du 
es nicht.

[guest (Gast)]

Wenn Dein Speilfeld nicht mindestens als

char * spielfeld[13][7];

deklariert ist knallt es.

Außerdem passt Dein Funktionsparameter "char **spielfeld" nicht wirklich 
zu den Zugriffen darauf (z.B. "spielfeld[i][j]"). Addressen von 
Zeichenketten zu vergleichen macht nur sehr selten wirklich Sinn.

[Peter II (Gast)]

guest schrieb:
> Außerdem passt Dein Funktionsparameter "char **spielfeld" nicht wirklich
> zu den Zugriffen darauf (z.B. "spielfeld[i][j]"). Addressen von
> Zeichenketten zu vergleichen macht nur sehr selten wirklich Sinn.


stimmt, 2 dimensionale Array kann man nicht universell an eine Funktion 
übergeben, das geht einfach nicht.

[Daniel S. (dani2304)]

#include <stdio.h>
#include <stdlib.h>
#define GROESSE_FELD 4
#define DIM_ZEILE (GROESSE_FELD * 2+2)
#define DIM_SPALTE (GROESSE_FELD * 2+2)


void spielGeruest(char **spielfeld){
int i=0, j=0;
spielfeld[0]=" 012345678";
spielfeld[1][0]='0';
spielfeld[2][0]='1';
spielfeld[3][0]='2';
spielfeld[4][0]='3';
spielfeld[5][0]='4';
spielfeld[6][0]='5';
spielfeld[7][0]='6';
spielfeld[8][0]='7';
spielfeld[9][0]='8';

for (i=1 ;i<(DIM_ZEILE); i++){
    for(j=1;j<(DIM_SPALTE);j++){
        if((i%2)){
            if((j%2)){
                spielfeld[i][j]='|';
        }
        else{
            spielfeld[i][j]='-';

        }
        }
        else{
            if((j%2)){
                spielfeld [i][j]='|';
            }
            else{
                spielfeld [i][j]='x';
            }
        }
        spielfeld[i][j+2]='\0';
    }
}
}




void ausgabeSpielfeld(char **spielfeld){
    int i=0;
    for(i=0;i<DIM_SPALTE;i++)
    printf("%s\n",*(spielfeld+i));

}

void sodokuVorlage(char **spielfeld){
    int i=0, j=0,x=0,y=0;
    for(i=0;i<DIM_ZEILE;i++)
    {
        for(j=0;j<DIM_SPALTE;j++)
        {
            if(spielfeld[i][j]=='x')
            {
                printf("Geben sie fuer x=%i und y=%i den gewuenschten Wert ein:",i-1,j-1);
                scanf("%c",&spielfeld[i][j]);
                fflush(stdin);
                while(spielfeld[i][j]!=' ' && spielfeld[i][j]!='1' && spielfeld[i][j]!='2' && spielfeld[i][j]!='3' && spielfeld[i][j]!='4')
                {
                printf("Falsche Eingabe!\nGeben sie erneut fuer x=%i und y=%i den gewuenschten Wert ein:",i-1,j-1);
                scanf("%c",&spielfeld[i][j]);
                fflush(stdin);
                }
                if(j>=9){
                    spielfeld[i][j]='\0';
                }
                fflush(stdin);
            }
        }

    }
}

    void sodokuStart(char **spielfeld)
    {
    int i=0, j=0, z=0,a=0,b=0, pz=0;
    int x[10],y[10];


    for(i=1;i<DIM_ZEILE;i++)
    {
        for(j=1;j<DIM_SPALTE;j++)
        {
           if(spielfeld[i][j]==' '){
                x[z]=i;
                y[z]=j;
                z++;
                pz=1;
            }
        }
    }
    while(pz==1){
    printf("Bitte geben Sie das zu aendernde Feld ein:\nZeile und Spalte: ");
    scanf("%i %i", &a, &b);
    fflush(stdin);
    a++;
    b++;
    while((a>9 || b>9)|| (a<=0 || b<=0))
    {
        printf("Dieses Feld existiert nicht. Bitte geben Sie ihre Eingabe erneut ein:");
        scanf("%i %i", &a, &b);
        a++;
        b++;
        fflush(stdin);
    }
    for(i=0;i<z;i++){
    if(x[i]==a && y[i]==b) goto weiter;
    }
    while(spielfeld[a][b]!=' ')
    {
        printf("Das ausgewae1hlte Feld darf nicht bearbeitet werden!  Bitte geben Sie ihre Eingabe erneut ein:");
        scanf("%i %i", &a, &b);
        a++;
        b++;
        fflush(stdin);
    }
    weiter: printf("Geben sie die auszufuellende Zahl ein:");
    scanf("%c",&spielfeld[a][b]);
    fflush(stdin);
    while(spielfeld[a][b]!='1' && spielfeld[a][b]!='2' && spielfeld[a][b]!='3' && spielfeld[a][b]!='4') {
        printf("Bitte nur eine Zahl zwischen '1' und '4' waehlen:");
        scanf("%c", &spielfeld[a][b]);
        fflush(stdin);
    }
    pz=0;
    for(i=1;i<DIM_ZEILE;i++)
    {
        if(pz==1) break;
        for(j=1;j<DIM_SPALTE;j++)
        {
           if(spielfeld[i][j]==' '){
            pz=1;
            break;
           }
           else pz=0;
        }
    }
    ausgabeSpielfeld(spielfeld);
    }
    }

    void sodokuCheck(char **spielfeld){
    int i,j,pruef=0;
    for(j=2;j<7;j+=2)
    {
            for(i=2;i<7;i+=2){
                    pruef=0;
                    printf("%i,%i",i,j);
                if(spielfeld[i][j]!=spielfeld[i+2][j] && spielfeld[i][j]!=spielfeld[i+4][j] && spielfeld[i][j]!=spielfeld[i+6][j]&& i==2){
                    printf("Erste");
                   pruef=1;
                    goto schleife;
                }
                if(spielfeld[i][j]!=spielfeld[i+2][j] && spielfeld[i][j]!=spielfeld[i+4][j] && i==4){
                    printf("Zweite");
                    pruef=1;
                    goto schleife;
                }
                if(spielfeld[i][j]!=spielfeld[i+2][j] && i==6){
                    printf("Dritte");
                    pruef=1;
                    goto schleife;
                }
                printf("Fehler in %i, %i",j,i);
                return;
                schleife:;
        }
    }
    }


int main(){
    char **Feld;
    int i;
    Feld=malloc(DIM_ZEILE * sizeof *Feld);
    for(i=0;i<DIM_ZEILE;i++){
        Feld[i] = malloc(DIM_SPALTE * sizeof **Feld);
    }
spielGeruest(Feld);
ausgabeSpielfeld(Feld);
sodokuVorlage(Feld);
ausgabeSpielfeld(Feld);
sodokuStart(Feld);
sodokuCheck(Feld);
return 0;
}

Hab mal alles gepostet. Ist aber lang ...

[Thomas M. (Firma: https://img.favpng.com/23/21/3) (thomasmopunkt)]

leider keine hilfreiche Antwort aber witzig ;-)
http://www.toodarkpark.org/computers/humor/shoot-self-in-foot.html

Pascal und Delphi gefallen mir :-)

[Peter II (Gast)]

> spielfeld[0]=" 012345678";

damit überschreibt du dir deinen Zeiger den du vorher per malloc geholt 
hast. Jetzt zeigt spielfeld[0] auf eine Datenbereich den du nicht ändern 
darfst. Damit stützt das Programm beim ersten schreibenden Zugriff auf 
spielfeld[0][x] ab.


Bitte fang noch mal neu mit dem Programm an, das ganze mit dem Zeiger 
auf Zeiger ist nicht sehr gut und viel zu kompliziert.

[Gerd E. (robberknight)]

Bei dem Programmierstil ist es kein Wunder daß Du da irgendwo einen 
Speicherzugriffsfehler drin hast und ihn nicht selbst in wenigen Minuten 
finden kannst:

- Einrückungen wie Kraut & Rüben
- Leerzeilen nach Lust & Laune
- Kein einziger Kommentar
- Mal #defines für die Speichergrößen, mal "for(j=2;j<7;j+=2)"
- Wackelige Speicherstruktur mit dem "char **spielfeld". Hier würde ich 
z.B. stattdessen ein struct empfehlen
- malloc ohne free
- keine Prüfung des Rückgabewerts von malloc (könnte auch NULL sein...)

Auch wenn Du den konkreten Fehler irgendwann findest, ist das Programm 
noch meilenweit von robust, wartbar und leicht verständlich entfernt. Es 
lohnt sich, auch schon bei vergleichsweise überschaubaren Programmen an 
sauberem Programmierstil zu arbeiten - dann geht das einem ins Blut über 
und man macht es bei komplexeren Programmen gleich von Anfang an 
richtig.

[Pfui (Gast)]

Das Thema malloc und Konsorten hatten wir doch vor ein paar Tagen 
schonmal.

Das Problem ist, dass Du ein Programm anfängst, dass recht umfangreich 
ist, ohne die Grundlagen von Zeigern und Arrays verstanden zu haben.

Das solltest Du erstmal gründlich durcharbeiten auch wenn es nicht 
sonderlich unterhaltsam ist.

Dein Code ist in der Tat lang. Deswegen steht über dem Formular für neue 
Beträge auch: "Längeren Sourcecode nicht im Text einfügen, sondern als 
Dateianhang"

Ich helfe gerne, auch bei verwickelten Problemen, aber eine Ansammlung 
von wiederholten Anfängerfehlern, mal abgesehen von der 
grottenschlechten Einrückung, ist meiner Meinung nach so leicht 
vermeidbar, dass die Präsentation solcher schon ganz leicht in die 
Richtung einer Unverschämtheit geht.

Also: Jetzt reiß Dich mal am Riemen und mach das richtig.

[Pfui (Gast)]

Ausserdem ist mir auch völlig schleierhaft, warum diese Herumgeraffel 
mit Defines nötig ist.

#define GROESSE_FELD 4
#define DIM_ZEILE (GROESSE_FELD * 2+2)
#define DIM_SPALTE (GROESSE_FELD * 2+2)


Die größe eines Sudoku-Feldes ist immer gleich.

Konstanten haben zweckmäßigerweise sowohl durch den Namen als auch durch 
ihren Wert, einen sinnvollen Zusammenhang zur Anwendung. Das ist hier 
nicht der Fall.

Das bedeutet aber auch, das ein malloc völlig überflüssig ist.

An sich ist das, wenn es richtig gemacht wird auch nicht schlimm, aber 
diese Kombination aus unzweckmäßigem Code und dann noch haufenweise 
Trivialfehlern ist doch ein wenig ärgerlich.

Deswegen fängt man eigentlich mit kleinen Programmen an bis man 
Trivialfehler weg hat und man liest mal ein paar Absätze über einige 
Basis-Algorithmen bis man in der Lage ist, ein wenig mehr vom 
Großen-Ganzen zu erkennen.

[Pfui (Gast)]

Davon mal abgesehen benötigt der Anfänger (in der überwiegenden Zahl der 
Fälle) auch kein Goto.

Es ist wohl wahr, dass das in einigen Fällen Code spart, aber für den 
Anfänger ist es viel lehrreicher, das im Fall der Fälle zu vermeiden und 
zu sehen wie der Code dann aussieht, wenn die anderen Kontrollstrukturen 
wirklich voll ausgenutzt werden. In Deinem Fall z.B. ist ein if-else if 
oft völlig ausreichend und auch offensichtlicher.

Da Goto aber ohnehin relativ selten wirklich Code spart und unnötig ist, 
ist es auch eine gute Daumenregel - jedenfalls für Anfänger.

[guest (Gast)]

guest schrieb:
> Außerdem passt Dein Funktionsparameter "char **spielfeld" nicht wirklich
> zu den Zugriffen darauf (z.B. "spielfeld[i][j]"). Addressen von
> Zeichenketten zu vergleichen macht nur sehr selten wirklich Sinn.

OK, das stimmt so natürlich nicht. Die passen schon zusammmen.
Allerdings hat Dein Feld nur 10 Elemmente, Du greifst aber in 
'sodokuCheck' auf 13 zu.

[Daniel S. (dani2304)]

Ja Problem ist, dass ist von der Aufgabe so vorgegeben ... Also mit 
**spielfeld und #define

[Daniel S. (dani2304)]

guest schrieb:
> guest schrieb:
>> Außerdem passt Dein Funktionsparameter "char **spielfeld" nicht wirklich
>> zu den Zugriffen darauf (z.B. "spielfeld[i][j]"). Addressen von
>> Zeichenketten zu vergleichen macht nur sehr selten wirklich Sinn.
>
> OK, das stimmt so natürlich nicht. Die passen schon zusammmen.
> Allerdings hat Dein Feld nur 10 Elemmente, Du greifst aber in
> 'sodokuCheck' auf 13 zu.

Inwiefern greife ich auf 13 zu?

[Kaj G. (Firma: RUB) (bloody)]

Mit diesem Code Beitrag "Re: Programmabsturz - Fehler unbekannt" 
gibt Valgrind folgende auskunft:

$ valgrind --leak-check=full -v ./main
==11136== Memcheck, a memory error detector
==11136== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==11136== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==11136== Command: ./main
==11136== 
...
==11136== Invalid write of size 1
==11136==    at 0x4007A9: spielGeruest (in /home/bloody/main)
==11136==    by 0x4011EE: main (in /home/bloody/main)
==11136==  Address 0x51d512a is 0 bytes after a block of size 10 alloc'd
==11136==    at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11136==    by 0x4011CB: main (in /home/bloody/main)
==11136== 
--11136-- REDIR: 0x4ec14d0 (libc.so.6:strchrnul) redirected to 0x4c31c60 (strchrnul)
--11136-- REDIR: 0x4eb7420 (libc.so.6:strlen) redirected to 0x4c2dba0 (strlen)
--11136-- REDIR: 0x4ebac40 (libc.so.6:__GI_mempcpy) redirected to 0x4c31e60 (__GI_mempcpy)
 012345678
==11136== Invalid read of size 1
==11136==    at 0x4C2DBB4: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11136==    by 0x4E7FE22: vfprintf (in /usr/lib/libc-2.24.so)
==11136==    by 0x4E86278: printf (in /usr/lib/libc-2.24.so)
==11136==    by 0x400810: ausgabeSpielfeld (in /home/bloody/main)
==11136==    by 0x4011F7: main (in /home/bloody/main)
==11136==  Address 0x51d512a is 0 bytes after a block of size 10 alloc'd
==11136==    at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11136==    by 0x4011CB: main (in /home/bloody/main)
==11136== 
...
==11136== Invalid read of size 8
==11136==    at 0x401015: sodokuCheck (in /home/bloody/main)
==11136==    by 0x40121B: main (in /home/bloody/main)
==11136==  Address 0x51d5090 is 0 bytes after a block of size 80 alloc'd
==11136==    at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11136==    by 0x4011AA: main (in /home/bloody/main)
==11136== 
==11136== Invalid read of size 1
==11136==    at 0x401019: sodokuCheck (in /home/bloody/main)
==11136==    by 0x40121B: main (in /home/bloody/main)
==11136==  Address 0x2 is not stack'd, malloc'd or (recently) free'd
==11136== 
==11136== 
==11136== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==11136==  Access not within mapped region at address 0x2
==11136==    at 0x401019: sodokuCheck (in /home/bloody/main)
==11136==    by 0x40121B: main (in /home/bloody/main)
==11136==  If you believe this happened as a result of a stack
==11136==  overflow in your program's main thread (unlikely but
==11136==  possible), you can try to increase the size of the
==11136==  main thread stack using the --main-stacksize= flag.
==11136==  The main thread stack size used in this run was 8388608.
2,2Erste4,2--11136-- REDIR: 0x4eb22f0 (libc.so.6:free) redirected to 0x4c2bccc (free)
==11136== 
==11136== HEAP SUMMARY:
==11136==     in use at exit: 180 bytes in 11 blocks
==11136==   total heap usage: 13 allocs, 2 frees, 2,228 bytes allocated
==11136== 
==11136== Searching for pointers to 11 not-freed blocks
==11136== Checked 65,336 bytes
==11136== 
==11136== 10 bytes in 1 blocks are definitely lost in loss record 1 of 3
==11136==    at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11136==    by 0x4011CB: main (in /home/bloody/main)
==11136== 
==11136== LEAK SUMMARY:
==11136==    definitely lost: 10 bytes in 1 blocks
==11136==    indirectly lost: 0 bytes in 0 blocks
==11136==      possibly lost: 0 bytes in 0 blocks
==11136==    still reachable: 170 bytes in 10 blocks
==11136==         suppressed: 0 bytes in 0 blocks
==11136== Reachable blocks (those to which a pointer was found) are not shown.
==11136== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==11136== 
==11136== ERROR SUMMARY: 39 errors from 5 contexts (suppressed: 0 from 0)
==11136== 
==11136== 1 errors in context 1 of 5:
==11136== Invalid read of size 1
==11136==    at 0x401019: sodokuCheck (in /home/bloody/main)
==11136==    by 0x40121B: main (in /home/bloody/main)
==11136==  Address 0x2 is not stack'd, malloc'd or (recently) free'd
==11136== 
==11136== 
==11136== 1 errors in context 2 of 5:
==11136== Invalid read of size 8
==11136==    at 0x401015: sodokuCheck (in /home/bloody/main)
==11136==    by 0x40121B: main (in /home/bloody/main)
==11136==  Address 0x51d5090 is 0 bytes after a block of size 80 alloc'd
==11136==    at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11136==    by 0x4011AA: main (in /home/bloody/main)
==11136== 
==11136== 
==11136== 18 errors in context 3 of 5:
==11136== Invalid read of size 1
==11136==    at 0x4C2DBB4: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11136==    by 0x4E7FE22: vfprintf (in /usr/lib/libc-2.24.so)
==11136==    by 0x4E86278: printf (in /usr/lib/libc-2.24.so)
==11136==    by 0x400810: ausgabeSpielfeld (in /home/bloody/main)
==11136==    by 0x4011F7: main (in /home/bloody/main)
==11136==  Address 0x51d512a is 0 bytes after a block of size 10 alloc'd
==11136==    at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11136==    by 0x4011CB: main (in /home/bloody/main)
==11136== 
==11136== 
==11136== 18 errors in context 4 of 5:
==11136== Invalid write of size 1
==11136==    at 0x4007A9: spielGeruest (in /home/bloody/main)
==11136==    by 0x4011EE: main (in /home/bloody/main)
==11136==  Address 0x51d512a is 0 bytes after a block of size 10 alloc'd
==11136==    at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11136==    by 0x4011CB: main (in /home/bloody/main)
==11136== 
==11136== ERROR SUMMARY: 39 errors from 5 contexts (suppressed: 0 from 0)
Speicherzugriffsfehler (Speicherabzug geschrieben)

clang mit -fsanitize=address liefert:

$ ./main
=================================================================
==11075==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000efda at pc 0x000000500433 bp 0x7ffee7053580 sp 0x7ffee7053578
WRITE of size 1 at 0x60200000efda thread T0
    #0 0x500432 in spielGeruest (/home/bloody/main+0x500432)
    #1 0x502c6e in main (/home/bloody/main+0x502c6e)
    #2 0x7fb3ac765290 in __libc_start_main (/usr/lib/libc.so.6+0x20290)
    #3 0x4186e9 in _start (/home/bloody/main+0x4186e9)

0x60200000efda is located 0 bytes to the right of 10-byte region [0x60200000efd0,0x60200000efda)
allocated by thread T0 here:
    #0 0x4c7ff8 in __interceptor_malloc (/home/bloody/main+0x4c7ff8)
    #1 0x502c1b in main (/home/bloody/main+0x502c1b)
    #2 0x7fb3ac765290 in __libc_start_main (/usr/lib/libc.so.6+0x20290)

SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/bloody/main+0x500432) in spielGeruest
Shadow bytes around the buggy address:
  0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9dd0: fa fa fa fa fa fa fa fa fa fa 00 02 fa fa 00 02
  0x0c047fff9de0: fa fa 00 02 fa fa 00 02 fa fa 00 02 fa fa 00 02
=>0x0c047fff9df0: fa fa 00 02 fa fa 00 02 fa fa 00[02]fa fa 00 02
  0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9e40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==11075==ABORTING

Und weil es soviel spass macht lassen wir auch noch splint ueber den 
Code laufen:

$ splint sudoko.c 
Splint 3.1.2 --- 23 Apr 2014

sudoko.c: (in function spielGeruest)
sudoko.c:10:1: Observer storage assigned to unqualified reference:
                  spielfeld[0] = " 012345678"
  Observer storage is transferred to a non-observer reference. (Use
  -observertrans to inhibit warning)
   sudoko.c:10:14: Storage becomes observer
sudoko.c:23:12: Test expression for if not boolean, type int: (i % 2)
  Test expression type is not boolean or int. (Use -predboolint to inhibit
  warning)
sudoko.c:24:16: Test expression for if not boolean, type int: (j % 2)
sudoko.c:25:17: Suspect modification of observer spielfeld[][]:
                   spielfeld[i][j] = '|'
  Storage declared with observer is possibly modified. Observer storage may not
  be modified. (Use -modobserver to inhibit warning)
   sudoko.c:10:14: Storage spielfeld[][] becomes observer
sudoko.c:28:13: Suspect modification of observer spielfeld[][]:
                   spielfeld[i][j] = '-'
   sudoko.c:10:14: Storage spielfeld[][] becomes observer
sudoko.c:33:16: Test expression for if not boolean, type int: (j % 2)
sudoko.c:34:17: Suspect modification of observer spielfeld[][]:
                   spielfeld[i][j] = '|'
   sudoko.c:10:14: Storage spielfeld[][] becomes observer
sudoko.c:37:17: Suspect modification of observer spielfeld[][]:
                   spielfeld[i][j] = 'x'
   sudoko.c:10:14: Storage spielfeld[][] becomes observer
sudoko.c:40:9: Suspect modification of observer spielfeld[][]:
                  spielfeld[i][j + 2] = '\0'
   sudoko.c:10:14: Storage spielfeld[][] becomes observer
sudoko.c: (in function sodokuVorlage)
sudoko.c:64:17: Return value (type int) ignored: scanf("%c", &spi...
  Result returned by function call is not used. If this is intended, can cast
  result to (void) to eliminate message. (Use -retvalint to inhibit warning)
sudoko.c:65:17: Return value (type int) ignored: fflush(stdin)
sudoko.c:69:17: Return value (type int) ignored: scanf("%c", &spi...
sudoko.c:70:17: Return value (type int) ignored: fflush(stdin)
sudoko.c:66:23: Suspected infinite loop.  No value used in loop test (i,
    spielfeld, j, spielfeld[], spielfeld[][]) is modified by test or loop body.
  This appears to be an infinite loop. Nothing in the body of the loop or the
  loop test modifies the value of the loop test. Perhaps the specification of a
  function called in the loop body is missing a modification. (Use -infloops to
  inhibit warning)
sudoko.c:75:17: Return value (type int) ignored: fflush(stdin)
sudoko.c:56:18: Variable x declared but not used
  A variable is declared but never used. Use /*@unused@*/ in front of
  declaration to suppress message. (Use -varuse to inhibit warning)
sudoko.c:56:22: Variable y declared but not used
sudoko.c: (in function sodokuStart)
sudoko.c:102:5: Return value (type int) ignored: scanf("%i %i", &...
sudoko.c:103:5: Return value (type int) ignored: fflush(stdin)
sudoko.c:109:9: Return value (type int) ignored: scanf("%i %i", &...
sudoko.c:112:9: Return value (type int) ignored: fflush(stdin)
sudoko.c:115:8: Value x[] used before definition
  An rvalue is used that may not be initialized to a value on some execution
  path. (Use -usedef to inhibit warning)
sudoko.c:115:19: Value y[] used before definition
sudoko.c:120:9: Return value (type int) ignored: scanf("%i %i", &...
sudoko.c:123:9: Return value (type int) ignored: fflush(stdin)
sudoko.c:126:5: Return value (type int) ignored: scanf("%c", &spi...
sudoko.c:127:5: Return value (type int) ignored: fflush(stdin)
sudoko.c:130:9: Return value (type int) ignored: scanf("%c", &spi...
sudoko.c:131:9: Return value (type int) ignored: fflush(stdin)
sudoko.c:128:11: Suspected infinite loop.  No value used in loop test (a,
    spielfeld, b, spielfeld[], spielfeld[][]) is modified by test or loop body.
sudoko.c: (in function main)
sudoko.c:185:9: Index of possibly null pointer Feld: Feld
  A possibly null pointer is dereferenced.  Value is either the result of a
  function which may return null (in which case, code should check it is not
  null), or a global, parameter or structure field declared with the null
  qualifier. (Use -nullderef to inhibit warning)
   sudoko.c:183:10: Storage Feld may become null
sudoko.c:187:14: Possibly null storage Feld[] derivable from parameter
                    spielGeruest (Feld)
  A possibly null pointer is reachable from a parameter or global variable that
  is not declared using a /*@null@*/ annotation. (Use -nullstate to inhibit
  warning)
   sudoko.c:185:19: Storage Feld[] may become null
sudoko.c:187:14: Passed storage Feld not completely defined (*(Feld[]) is
                    undefined): spielGeruest (Feld)
  Storage derivable from a parameter, return value or global is not defined.
  Use /*@out@*/ to denote passed or returned storage which need not be defined.
  (Use -compdef to inhibit warning)
   sudoko.c:185:9: Storage *(Feld[]) allocated
sudoko.c:188:18: Passed storage Feld not completely defined (*(Feld[]) is
                    undefined): ausgabeSpielfeld (Feld)
   sudoko.c:185:9: Storage *(Feld[]) allocated
sudoko.c:189:15: Passed storage Feld not completely defined (*(Feld[]) is
                    undefined): sodokuVorlage (Feld)
   sudoko.c:185:9: Storage *(Feld[]) allocated
sudoko.c:190:18: Passed storage Feld not completely defined (*(Feld[]) is
                    undefined): ausgabeSpielfeld (Feld)
   sudoko.c:185:9: Storage *(Feld[]) allocated
sudoko.c:191:13: Passed storage Feld not completely defined (*(Feld[]) is
                    undefined): sodokuStart (Feld)
   sudoko.c:185:9: Storage *(Feld[]) allocated
sudoko.c:192:13: Passed storage Feld not completely defined (*(Feld[]) is
                    undefined): sodokuCheck (Feld)
   sudoko.c:185:9: Storage *(Feld[]) allocated
sudoko.c:193:10: Fresh storage Feld not released before return
  A memory leak has been detected. Storage allocated locally is not released
  before the last reference to it is lost. (Use -mustfreefresh to inhibit
  warning)
   sudoko.c:183:5: Fresh storage Feld created
sudoko.c:8:6: Function exported but not used outside sudoko: spielGeruest
  A declaration is exported, but not used outside this module. Declaration can
  use static qualifier. (Use -exportlocal to inhibit warning)
   sudoko.c:43:1: Definition of spielGeruest
sudoko.c:48:6: Function exported but not used outside sudoko: ausgabeSpielfeld
   sudoko.c:53:1: Definition of ausgabeSpielfeld
sudoko.c:55:6: Function exported but not used outside sudoko: sodokuVorlage
   sudoko.c:80:1: Definition of sodokuVorlage
sudoko.c:82:10: Function exported but not used outside sudoko: sodokuStart
   sudoko.c:148:5: Definition of sodokuStart
sudoko.c:150:10: Function exported but not used outside sudoko: sodokuCheck
   sudoko.c:177:5: Definition of sodokuCheck

Finished checking --- 44 code warnings

Das sollten erstmal genug Hinweise auf moegliche Probleme sein.

[Pandur S. (jetztnicht)]

Debugging ist keine eigene Disziplin, sondern Teil der Programmierung. 
Ein programm sollte immer so aufgebaut sein, dass es Debugging 
unterstuetzt.

Da es sich hier um ein PC Programm handelt kann man komfortable 
Singel-steppen. Und sich bei jedem Schritt die Variablen anschauen, und 
mit den eigenen Vorstellungen vergleichen.

[Peter II (Gast)]

Oh D. schrieb:
> Da es sich hier um ein PC Programm handelt kann man komfortable
> Singel-steppen. Und sich bei jedem Schritt die Variablen anschauen, und
> mit den eigenen Vorstellungen vergleichen.

nur hilft das hier nicht wirklich weiter. Er macht einen schreibenden 
Zugriff auf Read-Only Daten. Im Debugger sieht er das was er erwartet.

[Pandur S. (jetztnicht)]

> Er macht einen schreibenden Zugriff auf Read-Only Daten.

Da meckert schon mein Compiler. Und falls nicht, wuerde ja beim 
naechsten Durchgang das Falsche drin stehen.

[Sudoku (Gast)]

Und: es heißt Sudoku, nicht Sodoku!

[Peter II (Gast)]

Oh D. schrieb:
>> Er macht einen schreibenden Zugriff auf Read-Only Daten.
>
> Da meckert schon mein Compiler.

nein macht er nicht, das kann er nicht überblicken.


> Und falls nicht, wuerde ja beim
> naechsten Durchgang das Falsche drin stehen.
stimmt auch nicht, das Programm stürzt ab, dann gibt es keinen nächsten 
Durchgang.

[Daniel S. (dani2304)]

Okay vielen Dank schonmal. Muss da auf jeden Fall noch viel Arbeit 
reinstecken :) Aber werde zuerst versuchen das Thema mit Pointern etc. 
besser zu verstehen.

[guest (Gast)]

Daniel S. schrieb:
>> OK, das stimmt so natürlich nicht. Die passen schon zusammmen.
>> Allerdings hat Dein Feld nur 10 Elemmente, Du greifst aber in
>> 'sodokuCheck' auf 13 zu.
>
> Inwiefern greife ich auf 13 zu?

Schau Dir die Schleife mit dem 'i' an, überleg wie groß 'i' wird und was 
dann innerhalb der Schleife bei 'i+6' passiert.