3. Stack-Heap-Kollision

Stack-Heap-Kollision

  • E

    Stack-Heap-Kollision: 😃
    Hat jemand so etwas schon in Realität erlebt? Gibt es dafür ein einfaches Demonstrationsprogramm (Assembler, C, C++)?

    0
  • P

    So etwas habe ich zuletzt 1992 mit Turbopascal auf einen 80286 mit 8088 FPO erlebt. Wenn der Stack zu klein eingestellt war und es beim Overflow zu einer dynamischen Erweiterung kam, haben die ST(0) bzw. ST(1) Steuerregister, die dann die Heaps der CPU "überschrieben".

    Es wurde dann zu einen FNSTSW (store status word) und ein FDECSTP (decrement stack-top pointer) ausgeführt.
    Solche Zenarien sind eigentlich mit der Integration der Co-Prozessoren in den CPU´s verschwunden (80486DX). Allerdings kann das Phenomän bei alten nativen 16-bit Maschinencode wieder auftauchen ... 😃

    0
  • E

    Du willst uns also Erzählen, dass du das mit 8 Jahren erlebt hast, ja 😃 ?

    0
  • T

    Ich besuchte das erste Schuljahr, als ich zum ersten Mal mit einer Stack-Heap-Kollision in Berührung kam. Damals dachte ich erst an eine unerlaubte Speicherüberschreibung meinerseits, was ich jedoch nach intensivem Debugging ausschließen konnte. Ich bastelte mir ein Workaround, bei dem der Stack auf die Festplatte ausgelagert wurde.

    0
  • E

    Man seid ihr alle kaputt heute... Im ersten Schuljahr klettert man auf Bäume, bewirft sich mit Schlamm oder bastelt sich einen Bogen in seiner Freizeit...

    0
  • T

    Hey Mann, das war ein Witz!
    In Wirklichkeit war es nämlich garkeine Heap-Stack-Kollision, sondern nur ein Paritätsfehler in den Speicherbausteinen 😉

    Nee. Als ich in der ersten Klasse war, habe ich mir in der Tat einen Bogen gebastelt bzw. von meinem Opa einen bauen lassen (der war größer als ich selbst)! 🙂

    0
  • T

    Der auch, damals noch 😃

    0
  • H

    der war größer als ich selbst

    Dein Opa? 😃

    [ Dieser Beitrag wurde am 31.05.2003 um 21:38 Uhr von HumeSikkins editiert. ]

    0
  • E

    Original erstellt von TomasRiker:
    **Hey Mann, das war ein Witz!
    **

    Na dann ist ja gut 😃

    0
  • X

    Original erstellt von etechniker:
    Du willst uns also Erzählen, dass du das mit 8 Jahren erlebt hast, ja 😃 ?

    nach deiner tollen logik wäre ich also 61 jahre alt. Du hast es raus.

    0
  • E

    Ist ja ein echt ulkiger Thread! 😃

    0
  • E

    Original erstellt von xroads42:
    nach deiner tollen logik wäre ich also 61 jahre alt. Du hast es raus.

    Ich meine nur mich zu erinnern dass Prof84 auch der Jahrgang sei... Außerdem ist es ja nicht so ungewöhnlich, sich entsprechend zu nennen... Besser tolle Logik als gar keine Logik ! 😡

    0
  • ?

    ich war 5 oder 6 Jahre alt, als ich diese Kollision erlebte.
    Es...es...es war schrecklich! ich wusste nicht wie das passieren konnte!!
    Ich rief zu erst meine Mama, die sagte, das sei normal auf einem 80286 mit 8088 FPO... puh war ich erleichtert, jetzt bin ich 23 und klettere auf Bäume und lasse mit einen Bogen von Omi Bauen während Opi das Esse zubereitet und Mama Sportschau guck und Papi mit seinen Freunden beim Shoppen ist.

    0
  • E

    Hat jetzt einer so'n Crash-Programm? 😃

    0
  • S

    Original erstellt von Prof84:
    **So etwas habe ich zuletzt 1992 mit Turbopascal auf einen 80286 mit 8088 FPO erlebt. Wenn der Stack zu klein eingestellt war und es beim Overflow zu einer dynamischen Erweiterung kam, haben die ST(0) bzw. ST(1) Steuerregister, die dann die Heaps der CPU "überschrieben".

    Es wurde dann zu einen FNSTSW (store status word) und ein FDECSTP (decrement stack-top pointer) ausgeführt.
    Solche Zenarien sind eigentlich mit der Integration der Co-Prozessoren in den CPU´s verschwunden (80486DX). Allerdings kann das Phenomän bei alten nativen 16-bit Maschinencode wieder auftauchen ... :D**

    bewusst erlebt habe ich das zwar noch noch nicht... (betonung auf bewusst. kann schon sein, dass sowas mal vorkam.)

    ...aber(in alle folgenden saetze gehoeren jeweils ca. 34.92924 afaik rein):
    du redest hier von floatingpoint zeuch.
    ein stack-heap konflikt hat aber genausowenig mit floatingpoint-rechnerei (die damals - wenn ueberhaupt - in einem externen koprozessor ablief) zutun, wie xroads42s benutzername mit seinem geburtsdatum.

    der bei dem konflikt beteiligte stack ist nicht der des koprozessors (der auf registern basiert), sondern der prozessoreigene stack im speicher.

    im heap bzw. datensegment liegen die daten des programms.
    dieses segment befindet sich an einem ende des verfuegbaren speicherbereichs.
    am anderen ende befindet sich der stack. wenn man nun ausgiebig pusht ohne zwischendurch mal ne runde zu poppen ueberschreibst du irgendwann deine variablen.

    allerdings weiss ich nicht, wieviel davon heute noch gilt.
    wahrscheinlich sehr wenig, da ja der speicherbereich auch nicht mehr fest ist.

    dass mit den enden hasse ich. man weiss nie was jetzt oben und unten ist.
    ist adresse 0x0 im speicher unten, oder ist sie oben?

    ich wuerde eine klaerende antwort, oder einige links zum thema dankend (noch staerker dankend als sich etechniker bei seinem opi fuer den bogen bedankt hat) annehmen.

    0
  • S
     

    sb@athlon$ cat push_erhard.s
.text
.global _start
_start:
        pushl   %eax
        jmp     _start
end:
        movl    $0, %ebx
        movl    $1, %eax
        int     $0x80

.data
.ascii "komm schon, ueberschreib mich!"

sb@athlon$ ./push_erhard 
Segmentation fault
sb@athlon$
    0
  • E

    ... wenn man nun ausgiebig pusht ohne zwischendurch mal ne runde zu poppen ...

    Einfach herrlich dieser Thread! 🙂
    Toller Code!

    0
Anmelden zum Antworten