Mit Zeigern System zerschießen????

[jaeggie]

Hallo liebe Forenmitglieder,

ich habe schon ein bisschen Erfahrung im Programmieren, habe bis jetzt aber immer die Arbeit mit Zeigern vermieden. Ich habe mich zwar eingelesen und auch alles verstanden (denke und hoffe ich), aber ich hab gehört, dass wenn man was falsch macht man sein System zerschießen kann.
Stimmt das?
Mir treibt es echt den Angstschweiß auf die Stirn, weil ich vertippe mich ganz oft oder übersehe mal etwas. Kann es wirklich so schlimm sein, wie in den Büchern beschrieben.

Könnt ihr mir vielleicht Tipps geben, wie ich mich schützen kann. Hab ja schon gehört, dass man einen Pointer immer mit 0 initialisieren soll, was ich auch mache. Aber wenn ich mit Arrays arbeite und aus Versehen versuche auf ein Element außerhalb des Arrays zuzugreifen, dann kann ja auch die Speicherzelle überschrieben werden.

Ich arbeite am Mac mit Xcode.

Danke schon jetzt für eure Antworten...

[Despotist]

habe bis jetzt aber immer die Arbeit mit Zeigern vermieden.

Das ist kein Fehler. Wenn man Zeiger verwenden will sollte man wissen was man tut was man aber wieder nur durch die Anwendung (und die Fehler damit) lernt. Es gibt aber auch viele Sprachen wo man sich darum keine Gedanken mehr machen muss (C# oder Java zum Beispiel). Ich persönlich finde das ganz angenehm.

dass wenn man was falsch macht man sein System zerschießen kann. Stimmt das?

Soweit ich weiß sollte mit einem Neustart alles behoben sein. Aber es gefällt dem OS nicht wenn es abgewürgt wird.

Könnt ihr mir vielleicht Tipps geben, wie ich mich schützen kann.

Alle Zeiger vor dereferenzierung auf 0 (null) testen. Alle offenen Programme haben ihren Inhalt gespeichert (das kommt von Krishty nochmal ;)). Wenn möglich fertige Zeigerklassen (smartpointer) oder Managerklassen verwenden. wissen auf welchen Typ der Zeiger zeigt und nur zu diesem casten.

Aber wenn ich mit Arrays arbeite und aus Versehen versuche auf ein Element außerhalb des Arrays zuzugreifen, dann kann ja auch die Speicherzelle überschrieben werden.

Das sollte eigentlich durch einen Crash verhindert werden.

Es hat auch jede Anwendung ihren eigenen Speicher also keine Angst aus Versehen was vom OS oder anderen Programmen zu überschreiben.

Du brauchst keine Angst davor zu haben solltest dir aber immer der Auswirkungen bewusst sein (wie immer beim Programmieren).

[Schrompf]

Nein, Du kannst Dir das System nicht zerschießen. Jedes aktuelle Betriebssystem (also auch MacOsX) hat Speicherschutz - jeder Prozess bekommt einen eigenen, virtuellen Adressraum. Und wenn Du auf Speicher zugreifst, den Du nicht vorher irgendwie allokiert hast, passiert nur eine Speicherschutzverletzung. Unter MacOsX, was ja einen Linux-Kernel benutzt, heißt das "Segmentation Fault". Probiere es aus: Initialisiere einen Zeiger mit irgendner Zufallszahl und greife darauf zu.

Code: Alles auswählen

int* meinZeiger = (int*) 0x12345678;
*meinZeiger = 5;

Ich weiß nicht, ob XCode was taugt, aber wenn Dein Programm von innerhalb der IDE aus gestartet wird, müsste bei so einem Fehler der Debugger hochkommen und Dir zeigen, welche Zeile die Speicherschutzverletzung verursacht hat. Dabei kannst Du auch gleich mal studieren, wie so ein Debugger aussieht und wie man mit ihm umgeht - lebenswichtiges Wissen für jeden Programmierer.

Es passiert Deinem Computer, dem Betriebssystem oder anderen Daten definitiv NICHTS! Also keine Sorge.

[Aramis]

Nein.

Das Betriebsystem kapselt deinen Prozess voellig gegen den Rest des Systems ab - die einzige Moeglichkeit, mit Zeigern dein System zu crashen, bestuende in direktem Zugriff auf einige systemkritische Datenstrukturen, wie z.b. die Interrupt-Tabelle, die Prozessliste oder, wenn du permanenten Schaden verursachen willst, den ungeschuetzten Page-Cache oder die zu deiner Festplatte gehoerenden IO Ports. Auf all diese Sachen hast du aber - egal was du machst, ausser, du findest zufaelligerweise eine Sicherheitsluecke - niemals Zugriff, sie werden vom Betriebsystem geschuetzt. Die Adressen, auf die ein Zeiger zugreifen kann und die somit den Rahmen der maximalen Zerstoerung definieren, erwecken zwar den Anschein, der komplette Adressraum des Systems zu sein, in Wahrheit werden jedoch alle Speicherzugriffe virtualisiert - du kannst maximal deinen eigenen Prozess zum Absturz bringen, das ist alles.

Anders sieht es natuerlich aus wenn du systemnah programmierst, z.b. auf Embedded-Geraeten ohne darunterliegendes Betriebsystem oder im Kernelspace eines Desktop-OS. Dort ist es zwar einfach, das System zu crashen, es aber dauerhaft zu zerstoeren ist auch dort nicht ganz so leicht und wohl kaum durch einen zufaellig falschen Zeiger zu erreichen.

Hab ja schon gehört, dass man einen Pointer immer mit 0 initialisieren soll, was ich auch mache.

Naja, ihn zu initialisieren ist eine gute Idee, aber wenn er tatsaechlich auf etwas zeigen soll, macht es wenig Sinn, ihn zuerst auf 0 zu setzen.

Pointer sind uebrigens alles andere als ungefaehrlich - bei falscher Anwendung schaffst du es problemlos, muehsam zu debuggende Programmfehler am laufenden Band zu produzieren. Daher ist es wichtig, dass du dir klarmachst, was ein Zeiger eigentlich ist, wofuer man sie ueberhaupt braucht, wie Zeigerarithmetik funktioniert und, wenn du mit C++ arbeitest, was Referenzen und Smart Pointer sind.

[jaeggie]

Na da bin ich aber beruhigt.
Ich danke euch sehr.

[Tiles]

Unter MacOsX, was ja einen Linux-Kernel benutzt, ...

Ist das nicht ein Unix Kernel?

[Sternmull]

Von wann sind denn deine Bücher? Die Aussage trifft auf Desktop-Systeme zu die vor über 10 Jahren gängig waren. Da konnte noch jeder Prozess im gesamten Speicher herumpfuschen. Ein Glück hatte ich damals noch keine Ahnung von Zeigern :)

Wie bereits geschrieben wurde kann man heutzutage nur auf Speicher zugreifen der dem Prozess durch das System zugeteilt wurde. Fehlerhafte Zeigernutzung wird, wie ebenfalls bereits geschrieben, in den meisten Fällen durch das Sytem oder Debug-Helfer erkannt und einem anschließend vor den Latz geknallt. Somit sind falsch verwendete Zeiger ungefähr genau so gefährlich wie alle anderen Programmierfehler: Wenn man versehentlich einen Befehl aufruft der einen Datenträger formatiert auf dem wichtige Daten waren, dann hat man halt pech gehabt. Aber von so was hab ich noch niemanden Berichten hören :)

[kimmi]

Diese Aussage trifft auch auf Geräte mit Embedded Linux zu, da diese oft keine MMU haben :). Die benutzt du aber wahrscheinlich nicht.

Gruß Kimmi

[Gandalf]

Unter MacOsX, was ja einen Linux-Kernel benutzt, ...

Ist das nicht ein Unix Kernel?

Alle guten Dinge sind drei. Es ist ein Mach Microkernel mit BSD Userland. Aber es ist ein zertifiziertes Unix, nutzt nur eben nicht den klassischen Kern. Der gesamte Kernel heißt XNU und das Basis Betriebssystem(welches Open Source ist) heißt Darwin.

[Tiles]

Danke :)

[starcow]

Ich denke wichtig ist das man hier zwischen zerschiessen und crashen unterscheidet. Für mich wäre zerschiessen ein Zustand, der auch nach einem Neustart noch anhält. Heisst, es sind definitiv Datei beschädigt / verändert worden. Oder gar einen Defekt der Hardware.
Ich persönlich verstehe ersteres darunter.
Ein System ohne Speicherschutz (wie Win95,98 etc. - klärt mich auf falls falsch) wirst du mit Zeiger auch nicht zerschiessen können - jedoch crashen.
Unter crashen verstehe ich: Nach reboot ist wieder alles ok.

Ich würd mal behaupten zerschiessen unter gar keinen Umständen - crashen ja, bei OS ohne Speicherschutz.

[Gandalf]

Ich denke wichtig ist das man hier zwischen zerschiessen und crashen unterscheidet. Für mich wäre zerschiessen ein Zustand, der auch nach einem Neustart noch anhält. Heisst, es sind definitiv Datei beschädigt / verändert worden. Oder gar einen Defekt der Hardware.
Ich persönlich verstehe ersteres darunter.
Ein System ohne Speicherschutz (wie Win95,98 etc. - klärt mich auf falls falsch) wirst du mit Zeiger auch nicht zerschiessen können - jedoch crashen.
Unter crashen verstehe ich: Nach reboot ist wieder alles ok.

Ich würd mal behaupten zerschiessen unter gar keinen Umständen - crashen ja, bei OS ohne Speicherschutz.

Ein mal ganz daneben.

Grundsatz 1: Es geht alles wenn man es denn will. Ein OS komplett zu zerlegen ist kein große Sache. Man muss nur eben den Speicherschutz umgehen oder eben das OS direkt angehen. >> z.B. wenn man einen Dateimanager schreibt der durch einen Fehler Systemdateien löscht, denn dann geht erstmal gar nichts mehr. Da Es aber immer wieder Entwickler gibt die glauben besser zu sein als die Betriebssystementwickler selbst, liefern einige Programme eigene "ersatz" Treiber aus, die bei Fehlverhalten sehr viel mist anstellen können.(das macht z.B. Sony) Zudem gibt es auch Entwickler die das Dateisystem umgehen und direkt auf die Platte schreiben, dabei kann auch recht viel schief gehen

2. Win9x hatte Speicherschutz. Aus Gründen der Abwärtskompatibilität war aber kein vollständiger Speicherschutz vorhanden.

3. Da z.B. unter Windows(>=XP) DirectX direkt im Kernel Layer liegt und nicht mehr wie bei älteren NT Versionen einen ebene darüber liegt, kann ein schlecht geschriebenes Spiel ohne Probleme das gesamte OS crashen. Gerade weil eben Grafikkartentreiber nicht unbedingt zu den stabilsten Treibern gehören.

Daher Speicherschutz funktioniert nur solange wie du mit ihm zusammen arbeitest. Wenn du gegen das OS arbeitest kann auch der beste Schutz nicht mehr helfen.

[joggel]

My 1 cent:
Also ich denke auch, man kann schon viel machen, wenn man es will.
Aber da muss man sich schon etwas auskennen ^^.
So als Anfänger, der beginnt mit Pointern zu arbeiten, ist das nahezu unmöglich, denke ich.
Aber zu dem geschützten Speicherbereich:
Diese werden doch vom OS verwaltet. Und wenn ein Programm die Berechtigung bekommt in so ein "prikären" Arbeitsspeicherbereich zu arbeiten, dann hat das auch meist seine Berechtigung..
So als Otto-Normal-Programmierer kommt man wahrscheinlich niemals in so eine Verlegenheit.

[Lynxeye]

Daher Speicherschutz funktioniert nur solange wie du mit ihm zusammen arbeitest. Wenn du gegen das OS arbeitest kann auch der beste Schutz nicht mehr helfen.

Dieses Fazit ist gefährliches Halbwissen. Wenn du es wirklich schaffst mit einem Userspace Programm den Speicherschutz auszuhebeln ist das ein Bug im Kernel. Der Kernel hat die Aufgabe alle Speicherbereiche zu schützen, egal was du tust und dort lässt dieser im Normalfall auch nicht mit sich reden. Kein Programm bekommt jemals die Berechtigung im Speicherbereich einer anderen Anwendung geschweige denn dem Kernel herum zu schreiben.

Die einzige Ausnahme dabei sind Treiber, denn die laufen logischerweise im Kernelspace und können damit auch nicht an der Ausführung von falschem Code gehindert werden. Deshalb hat ja Microsoft das Treiberzertifizierungsprogramm eingeführt.

Wichtig für den OP: Nein, du kannst in deinem Userspaceprogramm an den Zeigern herum pfuschen wie du willst, das schlimmste was passiert kann, ist das deine Anwendung mit einem Segfault abstürzt. Deine Anwendung kann nur in ihren eigenen Speicher schreiben, d.h. wenn du in einem Array über die Grenzen hinweg zugreifst machst du dir evtl. andere Daten deiner Anwendung kaputt. Das System an sich lässt sich davon aber nicht beeindrucken.

[Krishty]

Kein Programm bekommt jemals die Berechtigung im Speicherbereich einer anderen Anwendung geschweige denn dem Kernel herum zu schreiben.

Soso. Dann erklär mir mal, wie der Debugger neue Werte in meine Variablen reinzaubert, wenn ich das will. :)

Aber es stimmt natürlich, dass das dem OP nicht gelingen wird, so lange er nicht an ominösen Debugger-API-Funktionen rumpfriemelt.

[Lynxeye]

Kein Programm bekommt jemals die Berechtigung im Speicherbereich einer anderen Anwendung geschweige denn dem Kernel herum zu schreiben.

Soso. Dann erklär mir mal, wie der Debugger neue Werte in meine Variablen reinzaubert, wenn ich das will. :)

Aber es stimmt natürlich, dass das dem OP nicht gelingen wird, so lange er nicht an ominösen Debugger-API-Funktionen rumpfriemelt.

Debugger sind für mich keine normalen Anwendungen, denn genau aus genanntem Grund leben die auch zum Teil im Kernel.

Aber ich gebs ja zu, du hast mich bei einer überpauschalisierenden Aussage erwischt. Ich werde mich zur Strafe morgen noch mal durch den Linux mmap Code quälen. :x

[Aramis]

Nunja, streng genommen laufen Debugger ebenso im Userspace, jedenfalls Debugger fuer Userspace-Programme :-)

Jedenfalls ist das der Fall fuer gdb (der afaik ptrace nutzt), wie auch den MS-Debugger, der auf dem zu debuggenden Prozess bloss ein Rechte-Flag setzt und danach ueber ein paar WinAPI-Funktionen ziemlich beliebig in dessen Speicher rumschreiben kann. Korrigiert mich wenn ich was falsches sage.

(dass die besagten Systemfunktionen ihrerseits im Kernel leben ist klar, aber das trifft ja letztlich auf alle nativen APIs zu)

Korrekt ist allerdings, dass sich ein Prozess nicht ohne weiteres die Speicherbereiche eines anderen Prozesses in seinen eigenen Adressraum hineinmappen kann - das Injizieren einer DLL und das Starten eines eigenen Threads bzw. geschicktes Forken unter Linux kommt aber recht nahe an dieses Ziel heran.

[kimmi]

Windows-Debugger laufen im User-Space, ausser man hängt sich per serieller Schnittstelle mit einem Kernel-Debugger an einen Windows-Kernel. Weil wenn dem nicht so wäre und man setzt einen Breakpoint, wäre das zu debuggende System ( also der Windows-Kernel ) angehalten und dann ist's aus mit den Rückmeldungen :).

Gruß Kimmi