L'apprentissage de C++: Exemple de Stack Underflow en C++

Ce qui peut être un exemple simple en C++ qui provoque une pile de dépassement de capacité dans le cas de l'invocation et de retour d'appels de méthode. Je suis familier avec la convention d'appel, j'.e thiscall, stdcall et la cdecl et de la manière qu'ils le feraient de nettoyage de la pile. En particulier, ne Serait pas stack underflow être pris en charge par le code généré par le compilateur automatiquement pour moi ?

Quelles sont les situations qui peuvent me faire des ennuis avec pile-dépassement de capacité ??

Êtes-vous sûr que vous ne parlez pas de pile fil flux?
Je pense que vous avez le mauvais forum. C'est un Débordement de pile. Si vous voulez savoir à propos de stack UNDERflow, vous devriez visiter ce site. 😉 désolé, fallait le faire...
et @eeeeaaii - heu.. un stack underflow est un réel problème, mais pas quelque chose que vous exécutez dans souvent.
J'ai presque répondu à la question de la lecture de stackoverflow. Peut-être parce que de mon temps passé sur ce forum m'a fait lire à la pile underflow comme stackoverflow 🙂
costo: je pense que while (1) { __asm pop EAX } serait-il le faire (ce n'est pas la norme C++ bien sûr).

OriginalL'auteur Vishnu Pedireddi | 2011-07-01

  1. 10

    La seule façon que je peux voir ce qui se passe réellement serait si vous avez déclaré une fonction pour utiliser le stdcall (ou de toute autre convention d'appel qui spécifie le destinataire de l'appel de nettoyage de la pile) puis d'appeler la fonction par l'intermédiaire d'un pointeur de fonction qui a été défini comme un cdecl (ou de toute autre convention d'appel où la pile est nettoyé par l'appelant). Si vous faites cela, la fonction appelée apparaîtra à la pile avant de la retourner et puis l'appelant également pop de la pile conduisant à un dépassement de précision et des choses terribles.

    Dans le cas spécifique de fonctions de membre, la convention d'appel est généralement appelé thiscall et si l'appelant ou de l'appelé nettoie la pile dépend du compilateur.

    Voir ici pour les détails de l'appel d'conventions.

    cela pourrait-il aussi être causée par une mauvaise avant la déclaration d'une fonction? comme void foobar(int a); et dans un autre endroit void foobar(int a, int b);?
    Si vous utilisez la pile de cadrage correctement poping la pile n'est pas un problème.
    ce n'est pile le cadrage prévenir? L'OP demande sur les scénarios où ce qui pourrait aller mal, vous êtes ce qui suggère que la désactivation de la pile de cadrage permettrait cela?
    Pile le cadrage serait d'éviter les mauvaises arg-en-arg poping dans le cas d'incohérence de prototypage, n'est-ce pas?
    avez-vous une référence à ce que la Pile de cadrage est? Si vous êtes juste se référant à des conventions d'appel et de taille de cadre, alors il ne serait pas empêcher quoi que ce soit, parce que c'est sur le décalage des contrats.

    OriginalL'auteur Sean

  2. 5

    Je ne sais pas si vous parlez de la structure de données de la pile et de l'underflow problème ou quelque chose d'autre. Aussi loin que l' stack(data structure) underflow problème est en cause ici est une explication.

    stack est un dernier entré, premier sorti (LIFO) type abstrait de données et la structure des données. Une pile peut avoir n'importe quel type abstrait de données comme un élément, mais il est caractérisé par trois opérations fondamentales: pousser, pop et pile dessus.

    La pousser opération ajoute un nouvel élément au sommet de la pile, ou initialise la pile si elle est vide. Si la pile est pleine et ne contient pas assez d'espace pour accepter l'élément donné, la pile est alors considéré comme être dans un débordement de l'état. Le menu opération supprime un élément à partir du haut de la pile.

    Un pop soit révèle déjà des éléments cachés, ou des résultats dans une pile vide, mais si la pile est vide puis il va dans dépassement de capacité de l'état (C'est à dire pas d'éléments sont présents dans la pile à être retiré).

    La pile dessus opération permet d'obtenir les données à partir de la première position et la retourne à l'utilisateur sans le supprimer. Le même dépassement de capacité de l'état peut également se produire dans l'opération sommet de la pile si la pile est vide.

    Envisager une pile de mise en œuvre exemple:

    template <class Item> class Stack 
{
public:
    bool isEmpty() const;
    size_t size() const;
    Item pop();
    void push(const Item& it);
private:

};

    Considérons maintenant la suite des opérations effectuées sur cette pile.

    C++ command                      resulting stack
------------------------------------------------
Stack<int> S;
                                  _____ (empty stack of ints)



S.push(7);                            
                                  | 7 |  <-- top
                                  -----

S.push(2);                            
                                  | 2 |  <-- top 
                                  | 7 |
                                  -----

S.push(73);                           
                                  |73 |  <-- top 
                                  | 2 |
                                  | 7 |
                                  -----

S.pop();                           
                                  | 2 |  <-- top
                                  | 7 |                    -----
S.pop();      
                                  -----
S.pop();                           
                                  | 7 |  <-- top
                                  -----
S.pop();                           
                                  -----  (empty)

S.pop();                           
                    ERROR "stack underflow"
    Oui.. Merci pour l'explication très bien la situation. Mais, Précisément, je m'intéresse à l'apprentissage le cas où un stack underflow pourraient se produire lors de l'invocation ou de retourner les appels de méthode.
    pour l'image, tu vient de me faire comprendre stack underflow!

    OriginalL'auteur Alok Save

  3. 1

    Normalement, ce serait pris en charge par le compilateur. En réalité, la seule façon que je peux penser que vous pourriez accidentellement provoquer un stack underflow serait en appelant une méthode de mise en œuvre avec une convention d'appel comme si c'était l'aide d'une autre convention d'appel.

    Comme dans l'appel d'une invocation d'un appel de méthode définie avec une autre convention d'appel ??
    Yep, si le compilateur n'ai pas l'attraper, il suffit alors de mettre fin à une boucle qui n'a pas commencé donnerait underflow.

    OriginalL'auteur Eric Petroelje

  4. 1

    Si jamais vous êtes dans une position où un appel-stack underflow pourrait se produire, les chances sont que votre programme va mourir d'une mort violente avant qu'il n'arrive. Au moins, si je comprends bien la façon dont les appels de la fonction de travail est précis.

    En gros, le seul moyen pour elle de se produire est si vous appelez une fonction où le destinataire de l'appel nettoie la pile, et il soulève aussi de nombreuses valeurs... si l'appelant estime qu'une fonction accepte deux paramètres, mais le destinataire de l'appel prend en fait trois, ce qui pourrait arriver. Une variante serait une fonction où le destinataire de l'appel nettoie la pile, puis l'appelant nettoie la pile à nouveau, comme cela pourrait se produire si vous obtenez votre convention d'appel de mal. Dans les deux cas, vous obtiendrez probablement un problème, quand vous allez sur le lien et la déformation des noms sont faux, mais peut-être que vous venez de faire vraiment malchanceux.

    De toute façon, l'important, c'est que, après l'appel de la fonction, la pile est un ou plusieurs octets de moins que ce qu'il est censé être. Théoriquement, le programme se poursuivra ensuite, avec la bonne quantité de données, mais en restant à un ou plusieurs octets court de ce qui est attendu. Finalement, il n'y a plus de données à pop off, et vous avez un stack underflow.

    Cependant, lorsqu'il se référera à la pile, les adresses sont par rapport à la partie supérieure. Ainsi, le compilateur va chercher un objet particulier à [haut de la pile + 3] si elle est de trois octets du haut de la pile. Il va encore le faire si la pile en finit plus courte que prévue, et de regarder pour que l'objet est au mauvais endroit. En supposant que l'objet est encore toujours là... il serait peut-être accidentellement obtenu sauté déjà. Lorsque vous arrivez à la fin de quelque fonction que vous faites, il pourrait ne pas être en mesure de trouver la bonne adresse de retour pour cette même raison, mais même si elle le fait, d'avoir tous vos objets soudain corrompu est une jolie situation désastreuse.

    Mise en garde: c'est basé sur l'hypothèse que les systèmes modernes se comportent de la même que l'ancienne microcontrôleurs j'ai l'habitude de travailler sur une dizaine d'années. Peut-être qu'ils sont plus intelligents que ça maintenant.

    OriginalL'auteur Dennis Zickefoose