Wat is een stapeloverloop?
Stack overflow is een programmeerfout waarbij een poging om gegevens naar een bepaald geheugenblok te schrijven mislukt omdat er geen ruimte meer over is in het blok. Dit type fout gebeurt op dezelfde manier als bufferoverlopen, heapoverlopen en stapelbufferoverlopen. Het verschil tussen dit soort fouten is afhankelijk van de gebruikte gegevensstructuur van de computer en het gemeenschappelijke kenmerk is dat er een poging plaatsvindt om meer gegevens te schrijven dan er ruimte is om deze vast te houden.
Symptomen van een stack-overflow kunnen variëren, afhankelijk van de gebruikte computertaal en de beschikbare machines voor foutrapportage. In C ++ manifesteert een stack-overflow zich vaak als een segmentatiefout en vaak wordt er geen aanvullende informatie gegeven om te bepalen waar of hoe de overflow is opgetreden. Een overloop in Java resulteert vaak in een crash van een virtuele machine die een redelijk gedetailleerd foutenbestand oplevert. Ongeacht de taal waarin een overloop plaatsvindt, kan de overloop vrijwel altijd worden gecorrigeerd door de juiste foutopsporing en identificatie van de oorspronkelijke overloopbron.
Computertalen die expliciet geheugenbeheer bieden, zijn vaak gemakkelijker te beveiligen tegen stack-overflow. Algemeen geaccepteerde programmeerpraktijken dicteren meestal dat voor elk segment van het geheugen dat een programma toewijst, het programma zichzelf ook moet verwijderen. C ++ staat dit mechanisme toe en zorgvuldige monitoring op deze manier kan de hoeveelheid geheugen die een programma gebruikt tot een minimum beperken. Talen die geen expliciet geheugenbeheer bieden en in plaats daarvan impliciet geheugenbeheer gebruiken, zijn moeilijker te beschermen tegen stapeloverloopfouten. Java verwerkt zijn eigen geheugen in zijn virtuele machine, dus gegevens kunnen niet expliciet worden verwijderd om ruimte te maken voor meer.
Een veelgemaakte fout van beginnende programmeurs is om aan te nemen dat een stack-overflow niet kan plaatsvinden in computertalen die met hun eigen geheugenbeheer omgaan. Hoewel dit in het begin aannemelijk lijkt, is dit niet het geval. Talen met impliciet geheugenbeheer hebben vaak afvalverzamelaars die onnodige geheugenblokken vrijmaken, maar deze afvalverzamelaars werken niet altijd op het tijdstip dat een programmeur verwacht. Op vuilnismannen vertrouwen is relatief gevaarlijk en het kan een programma niet altijd beschermen tegen een overloopfout.
Overloopfouten kunnen catastrofaal zijn en een heel programma stoppen, of ze kunnen bijna stil zijn en een programma toestaan om verder te gaan. Deze tweede soorten fouten zijn vaak het moeilijkst te vinden omdat er een fout kan optreden die eerder is veroorzaakt door een overloop van vele regels code. Bij een stack-overloop hoeft u vaak niet door een heel programma te zoeken, maar hoe langer een programma na een overloop kan worden uitgevoerd, hoe moeilijker de fout kan zijn om te vinden en op te lossen.