Diskussion:Schutzverletzung

mesite Systeme

"Auf den mesiten Systemen" meiner Meinung nach zu schwach für die Schutzverletzung

MMn sorgt das eigentlich immer und überall für eine Schutzverletzung oder vegleichbares, weil das etwas C-eigenes ist, unabhängig vom System. Habe die Aussage daher etwas verstärkt

Schutzverletzungen sind nichts C-eigenes sondern eine Sache des betriebsystems. So kann z.B. auf einem Atmel keine Schutzverletzung auftreten, da auf den gesamten Speicher zugegruffen werden kann (ist ja auch unnötig, da keinerlei andere "Processe" laufen (die es eigtl. nicht gibt).

Einzig und allein der Kernel entscheidet, ob etwas eine Schutzverletzung ist. Ein weiteres beispiel ist der Kernel selber: dieser ist auch in C geschrieben und kann (und muss) nach belieben über den Speicher herrschen. (nicht signierter Beitrag von 92.204.69.49 (Diskussion) 01:50, 22. Okt. 2010 (CEST))

Lösungsweg für C-Beispiel

Es wäre schön, wenn nach dem C-Beispiel ein Lösungsweg steht, wie man es üblich oder besser machen kann, dass eben keine Schutzverletzung auftritt. Weiß da wer, wie das sonst geht? (nicht signierter Beitrag von 77.116.100.35 (Diskussion | Beiträge) 10:34, 18. Jan. 2010 (CET))

Lösung? naja in C selber gibt es da nur eine Lösung: Aufpassen: Solche Fehler entstehen entweder durch fehlerhafte Pointerarithmetik (z.B. oft bei Buffern oder Zeichenketten, die nicht ordentlich mit '\0' abgeschlossen sind) oder bei zugriffen auf zuvor freigegebene Speicherblöcke:

Bsp Free:

char *p = malloc(100);
strcpy(p, "Wikipedia"); //OK
free(p);
strcpy(p, "Schutzverletzung"); //ARG!!

Beispiel Pointerarithmetik:

char text[] = "Wikipedia"; //Chararray der Länge 10 (9 Zeichn + '\0')
char *p=text; //Pointer auf erstes Zeichen des textes (hier 'W')
while(*p) //Solange zeichen nicht null 
{
   printf("%c ", *p); //gebe Zeichen + Leerzeichen aus 
   p++; //Nächstes Zeichen
}
//Ausgabe: W i k i p e d i a

text[9] = '!'; // '\0' mit '!' überschreiben

p=text;
while(*p) //Solange zeichen nicht null 
{
   printf("%c ", *p); //gebe Zeichen + Leerzeichen aus 
   p++; //Nächstes Zeichen
}

//Ausgabe (Wahrscheinlich): W i k i p e d i a ! 
SEGMENTFAULT

Grund: nach dem ! versucht das Programm auf einen (wharscheinlich) nicht Reservierten Speicher zuzugreifen!

Selbes Problem besteht bei allen string functionne die die Länge des Buffers nicht überprüfen: Bsp: strcpy (schlecht) => strncpy (gut) :) (nicht signierter Beitrag von 92.204.69.49 (Diskussion) 01:50, 22. Okt. 2010 (CEST))

Treiber

Schlecht pogrammierte Treiber gehören zu den häufigsten Ursachen von Schutzverletzungen und sollten daher mMn gesondert bei den Beispielen erwähnt werden. --84.114.48.34 19:02, 28. Jan. 2012 (CET)

Ergänzt. Gruß --Cvf-ps^Disk_+/− 19:03, 27. Jun. 2012 (CEST)

Schutzverletzung unter Fortran notorisch?

1. Warum?
2. Wo ist diese Info her?
3. Was hat eine Schutzverletzung mit der konkret verwendeten Programmiersprache zu tun? Es ist ein Bug, sonst nichts!
4. Warum gerade in Fortran "notorisch"?
5. Warum? (nicht signierter Beitrag von 84.119.77.120 (Diskussion) 20:00, 28. Mär. 2012 (CEST))

AW zu 1-5: unbelegte Aussage entfernt. --Cvf-ps^Disk_+/− 19:13, 27. Jun. 2012 (CEST)

Ausnahme 13

Sollte das nicht eher 0x0D heißen? Soviel ich weiß ist da die Hexadezimal-Notation üblich, die Benutzer, die noch Windows 9x kennen, kennen wohl den BSOD über den schweren Ausnahmefehler 0D, der wohl nach 0E der zweithäufigste ist. Dabei handelt es sich um die allgemeine Schutzverletzung, siehe BSOD#Konzept. --MrBurns (Diskussion) 20:15, 27. Jun. 2012 (CEST)

Habe die Hexwerte (aus dem Grund, dass der OMA-Benutzer das evtl. in der anderen Darstellung gar nicht erkennt) eingebaut. Eigentlich ist das aber dasselbe; aus einer dezimalen 11 (13) wird durch Darstellung als hexadezimale B (DD) ja keine andere Zahl, es wird nur dieselbe anders dargestellt. Gruß --Cvf-ps^Disk_+/− 20:40, 27. Jun. 2012 (CEST)