Diskussion:Forkbomb

aus Wikipedia, der freien Enzyklopädie

C-Code

Bei mir funktioniert while(fork()) nicht bzw. es stürzt nicht ab. Müsste daran liegen, dass die Kind-Prozesse abbrechen, da fork() in einem Kindprozess 0 zurückliefert. Ohne Bedingung hat man jedenfalls einen garantierten Absturz, weswegen ich while(fork()) mit for(;;)fork(); getauscht habe.

Äh.. Nur mal so ne Frage, aber wirft da der Compiler nicht die Warnung, das es die Fork-Funktion nicht gibt? -- Master_M (nicht signierter Beitrag von 188.23.51.172 (Diskussion) 20:04, 5. Jun. 2010 (CEST))
Bei solchen Beispielen ist es durchaus üblich offensichtlich notwendige include-Anweisungen oder ähnliches wegzulassen, um das Beispiel kurz und knapp zu halten bzw. nicht vom wesentlichen abzulenken. --Gms 23:51, 8. Jun. 2010 (CEST)

Java-Code

Der Java-Code in der jetzigen Fassung erzeugt keine neuen Prozesse, sondern neue Threads, d.h. von der Betriebssystem-Seite bleibt es bei genau einem Prozess. Die immer mehr werdenden Threads nehmen natürlich auch immer mehr Ressourcen in Anspruch bis sich das Programm irgendwann (vermutlich mit out-of-memory) aufhängen wird. Die Maschine als solche ist (wenn man nicht noch andere Fehler einbaut) nicht dadurch (ressourcenmäßig) gefährdet. Insofern ist das Java-Beispiel kein passendes Beispiel für eine Forkbomb. (nicht signierter Beitrag von 94.217.96.68 (Diskussion) 13:07, 22. Dez. 2012 (CET))

Nicht ganz korrekt!

"Aus einem Programmaufruf werden somit zunächst 2, dann 4, dann 8 und nach nur 10 solcher Zyklen sind bereits über tausend Kopien gestartet und aktiv."

Das stimmt mathematisch, der Realität entspricht es nicht. Die "Forkbomb" ist wie ein binärer Baum. Das beduetet, das jede Ebene die Zahl der Forks verdoppelt (soweit OK). Ein PC kann aber nicht in der gleichen Zeit, wie er 2 Forks startet, dan 4 Forks, 8 Forks, 16 Forks usw. gleichzeitig starten.

Der Computer benötigt also zum starten von 4 Forks die doppelte Zeit, wie das Starten von 2 Forks. Dementsprechend benötigt er für 8 Forks die vierfache Zeit, und für 512 Forks die 256 fache Zeit.

Wird das Programm rekursiv abgearbeitet, dann wird überhaupt nur ein Zweig abgearbeitet, und die Verästellungen werden gar icht erst durchlaufen.

Ach ja, da der Computer eine Obergrenze an aktivrn Prozessen haben wird, werden ab einem bestimmten Moment Prozesse in den Swap-Speicher ausgelagert werden, was den Ablauf noch verlansamt. Spätestens, wenn der Swap-Speicher voll ist ist Schluß.

Nebenbei: 1990 habe ich mal auf einer UNIX-Workstation etwas ähnliches laufen lassen. Das Program war ein Script, das im Hintergrund lief. Zweck des Programms war es, rekursiv einen vorgegebenen Binomialkoeffizienten zu berechnen, und zwar in dem Sinne, das jeder Scriptaufruf bis zu zwei weitere Scriptaufrufe zur Folge haben konnte, uns solange wartete, bis die aufgerufenen Scripte ihr Ergebnis zurücklieferten:

binkoeff n k -> binkoeff n-1 k + binkoeff n-1 k-1

Abbruchbedingungen:

binkoeff n 1 = 1 binkoeff n n = 1

Ein binkoeff 49 6 erzeugt also maximal an die 14 Millionen binkoeff Aufrufe. --Arbol01 01:18, 14. Dez. 2008 (CET)

Bist du dir mit der doppelten Zeit sicher? Nur weil ein Computer, sagen wir jetzt mal 1 Sekunde braucht um 2 solcher Forks zu starten, muss das nicht unbedingt heißen, dass er fuer 4 oppelt so lange braucht. Höchstens wenn das Erstellen eines Forks ihn voll auslastet, so dass er fuer jeden Fork gleich lange braucht, ich denke heutige Computer sind in der Lage 2 oder 4 Forks in der selben Zeit zu erzeugen, kann auch sein, dass ich mich irre, wenn ja, da korrigier mich bitte. -- Jorumpl 19:27, 19. Aug. 2009 (CEST)
Deinem Zweifel würde ich auch zustimmen, das sollte möglichst allgemein gehalten werden. Felix D. (Diskussion) 17:27, 4. Sep. 2018 (CEST)

Phyton Code

Der Phython Code ist kein Forkbomb, der ruft das Fork nicht rekursiv sondern in einer einfachen Schleife auf. Sollte den selben Effekt haben, aber ist laut der vorherigen Definition keine Forkbomb.

Ohne auch nur ein Fitzelchen Python zu können würde ich das dann so vorschlagen:
import os
os.fork()
os.fork()
-- RAMI 21:15, 18. Mär. 2009 (CET)
Ich habe den Pythoncode mal rausgenommen, bis die Sache sicher geklärt ist. MfG, --Dr. Al. K. Lisch ?!  +/- 11:46, 30. Jul. 2009 (CEST)

Ergänzung zur Forkbomb

ich würde das hier aus dem englischen wiki noch ergänzen: 

:()      # define ':' -- whenever we say ':', do this:
{        # beginning of what to do when we say ':'
    :    # load another copy of the ':' function into memory...
    |    # ...and pipe its output to...
    :    # ...another copy of ':' function, which has to be loaded into memory
         # (therefore, ':|:' simply gets two copies of ':' loaded whenever ':' is called)
    &    # disown the functions -- if the first ':' is killed, all of the functions that it has started should NOT be auto-killed
}        # end of what to do when we say ':'
;        # Having defined ':', we should now...
:        # ...call ':', initiating a chain-reaction: each ':' will start two more.

ich bin mir sicher, nicht jeder kann mit RegEx aus dem FF umgehen --Unterstrichmoepunterstrich 11:51, 12. Nov. 2009 (CET)

RegExp? So ungefähr hieße das ganze auf Dschörmän: 

:()      # Definition der Funktion ":" -- immer wenn ":" aufgerufen wird, tue das folgende:
{        # 
    :    # eine neue Kopie von ":" laden
    |    # ... und seine Standardausgabe umleiten auf ...
    :    # ... eine weitere Kopie von ":" (die auch im den Speicher geladen werden muss)
         # (":|:" erzeugt also einfach 2 Kopien von ":", immer wenn es aufgerufen wird)
    &    # die Befehlszeile unabhängig vom aufrufenden Prozess machen (im Hintergrund ausführen)
}        # 
;        # Nach der Definition von ":"
:        # ... wird durch einen Aufruf ":" die Kettenreaktion in Gang gesetzt.

(nicht signierter Beitrag von 78.42.199.69 (Diskussion | Beiträge) 20:08, 20. Nov. 2009 (CET))

Javascript-Beispiel

Das Javascriptbeispiel ist auch keine Forkbomb, es ist einfach nur eine Endlosschleife. Sinnvoller wäre 

function f(f) {
 f(f());
}

Und wie wäre es mit einem weiteren Beispiel für bash? 

$0 | $0 &

--Twinity 15:44, 1. Mär. 2010 (CET)


Auch Dein Javascriptbeispiel ist keine Forkbomb. Es wird einfach nur in eine Endlosrekursion gegangen. Da man anscheinend in Javascript keine Prozesse erzeugen kann, kann man wohl mit Javascript prinzipiell keine Forkbomb schreiben.

Bei Bash (oder vielleicht sowieso besser allgemeiner auf bourne shell beziehen) ist die Frage, wieviel Varianten im Artikel sinnvoll sind - 2 reichen vielleicht? --Gms 20:28, 2. Mär. 2010 (CET)

Das das keine Forkbomb ist, ist natürlich klar, ist mit Javascript auch gar nicht machbar. Halte es aber für sinnvoller als in einer Endlosschleife Fenster zu öffnen, oder? -- Twinity 15:13, 3. Mär. 2010 (CET)

Na dann ist es doch sinnvoller das Java-Script Beispiel zu entfernen. Man kann ja im Artikel drauf hinweisen, dass man in Sprachen wie JavaScript keine Fork-Bomb schreiben kann. Ist vielleicht nicht jedem Leser direkt klar. --Gms 21:49, 16. Mär. 2010 (CET)

Artikel in sich nicht Stimmig

Hab den Artikel zur Ueberarbeitung markiert.

  • Die Kurzsusammenfassung spricht von einer linearen Rekursion mit Stack Overflow.
  • Daneben wiederum steht ein Bild einer exponentiell wachsenden Rekursion
  • Das Beispiel in Pseudocode spiegelt die exponentielle Variante wieder
  • Die Quelltextbeispiele sind gemischt, mal lineare mal exponentiell wachsende Rekursion.

IMO: Ist die lineare Rekursion keine Forkbombe, sondern lediglich die Exponentielle, da nur hier das "explosionsartige" Wachstum der Prozessanzahl zum tragen kommt. Ganz gleich dessen jedoch sollte der Artikel dahingehend klargestellt werden und eine einheitliche Linie zeigen um Verwirrung zu vermeiden. -- C m 16:22, 3. Nov. 2010 (CET)

Nachtrag: Das in der Zusammenfassung genannte "Aufruf[en] des Systemcalls fork in einer Endlosschleife" (siehe C beispiel) ist keine(!) Rekursion und widerspricht damit der eigenen Definition ... -- C m 16:34, 3. Nov. 2010 (CET)
Doch, es findet eine Rekursion statt. Eine Funktion ist rekursiv, wenn sie sich selbst aufruft. Analog dazu: Ein Programm ruft sich rekursiv selbst auf via fork ... --Gms 20:06, 19. Nov. 2010 (CET)
daraus ergibt sich auch interessantes fuer die Beispiele: alle Beispiele die eine Schleife zum Forken nutzen entsprechen nicht ", rekursiv Kopien seiner selbst zu starten" (Betonung auf "rekursiv") und koennen somit entfehrnt werden ;-> -- C m 16:43, 3. Nov. 2010 (CET)
Doch, siehe Antwort zum vorherigen Nachtrag. --Gms 20:06, 19. Nov. 2010 (CET)
  • Wo spricht die Kurzzusammenfassung von einer **linearen** Rekursion? Oder einem Stack Overflow?
  • Bild und Pseudo-Code sind stimmig zueinander
  • Selbst lineares Wachstum via Fork entspricht der Definition in der Einleitung (rekursiver Aufruf). Man könnte den Verweis auf das Pseudo-Code Beispiel umformulieren, z.B. 'Der folg. Pseudo-Code stelle eine Forkbomb mit exp. Wachstum dar.' Das wäre klarer
  • Unabhängig davon - welche Beispiele meinst du, die nur lineares Wachstum erzeugen?
--Gms 20:06, 19. Nov. 2010 (CET)

Kurzzusammenfassung

Die Kurzzusammenfassung ist meines Erachtens schon deshalb schlecht, weil sie den Begriff "Forkbomb" viel zu eng faßt: im Grunde kann doch jedes Programm, daß durch - rekursive oder nicht-rekursive - Mittel so lange Prozesse startet, bis die Prozeßtabelle überlädt (oder das Memory alle ist, was auch immer früher eintrifft), als "Forkbomb" bezeichnet werden. Daraus könnte man zB auch die - Anfängern immer wieder passierende - unabsichtliche Programmierung von Forkbomben ableiten: Programme, die das, was sie tun, mit einem Übermaß an zusätzlichen Prozessen tun, sodaß sie vielleicht mit kleinen Testdatensets gerade noch laufen, aber im realen Betrieb das System gegen die Wand fahren. --bakunin (Diskussion) 11:22, 14. Mai 2013 (CEST)

PAM beschränkt Prozeßanzahl

Im Artikel steht zur Zeit:

Der konkrete Effekt einer Forkbomb hängt in erster Linie von der Konfiguration des Betriebssystems ab. Beispielsweise erlaubt PAM auf Unix- und Unix-ähnlichen Betriebssystemen die Zahl der Prozesse und den maximal zu verbrauchenden Speicher pro Benutzer zu beschränken.

Das ist völliger Unsinn: Erstens ist PAM (noch) kein Standard - und deshalb auch nicht "UNIX" - sondern nur vorläufig, siehe "XSSO". Zweitens wird die maximale Prozeßanzahl und die maximal zuzuteilende Memory-Menge pro User nicht von der PAM geregelt (was auch der Name - "Authentication Modules" - nahelegt), sondern durch den Kernel, der sich durch die PAM (sofern sie überhaupt verwendet wird, was nicht notwendigerweise der Fall ist) verifizieren läßt, wer der User grade ist. (->"Authentizierung") Beispielsweise stehen bei AIX diese Beschränkungen in /etc/security/limits in Stanza-Form (und vermutlich auch irgendwo in der ODM, ich habe noch nie danach gesucht) und die User-Verwaltung bedient sich dort. --bakunin (Diskussion) 11:40, 14. Mai 2013 (CEST)

Endlosschleife

Warum wird der Prozess in einigen Codebeispielen in einer Endlosschleife geforkt (vgl. C und PHP), obwohl es doch reichen sollte lediglich 2 Kopien seiner selbst zu erstellen (so wie es auch im Teil mit 2^n Kopien erklärt wird)? --MorbZ 08:55, 21. Apr. 2013 (CEST)

Abgerufen von „https://de.wikiup.org/index.php?title=Diskussion:Forkbomb&oldid=210785363“