exception: Stack overflow

Version imprimable

30/08/2013, 15h08
ame_12

exception: Stack overflow

Bonjour,

Pour les besoins d'une application, je dois afficher et actualiser quelque donn�es que je r�cup�rer depuis un carte.
Le probl�me que je rencontre est dans l'actualisation des donn�es : j'utilise un thread qui parcours tous les donn�es et demande � la carte leur nouvelle valeur une par une.
Au bout d'un moment, j'ai un d�passement de pile ( Stack overflow at 0xXXXXXXX), qui intervient toujours au m�me endroit: lors de la r�cup�ration d'une valeur.

Quelqu'un peut me dire qu'est ce qui peut cause ce d�passement de pile ?
Merci pour vos r�ponses.
30/08/2013, 15h16
Iradrille

Hello,

G�n�ralement �a vient de fonctions r�cursives : trop d'appels imbriqu�s => stack overflow.

Post le bout de code qui pose probl�me, �a sera plus simple que de jouer aux devinettes pour trouver le vrai probl�me. ;)

le code est tr�s long mais voici le bout de code (simplifier) o� l�exception est lev�e:

Code:

1
2
3
4
5
6
7
 // ce qui permet de lancer le thread: 
this->hDataThread = CreateThread ( NULL,             
                                0,      //  Est ce qu'on peut spécifier une taille plus grande pour eviter le depassement?                       
                                &dwThreadStart,    
                                this,                             
                                0,                               
                                &this->dwThreadId );

Code:

1
2
3
4
5
6
 // Le thread 
DWORD WINAPI CMaClass::dwDataThreadStart( void* pvThreadParam )
{
    CMaClass* pThis = (CMaClass*)pvThreadParam;
    return pThis->dwThread(  );
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
DWORD CMaClass::dwThread(  )
{
 
    EError eError;
    do
    {
        for (int iListIndex = 0; iListIndex < this->xmlDataList->GetCount(); iListIndex++)
        {
                AnsiString szValue = L"";
                _di_IXMLStandardTestV1_Field xmlUsage = xmlDataList->Get_Field(iListIndex);
                szValue = szGetValue( xmlUsage );   // <== cette fonction appelle une fonction d'une autre dll ou il y a beacoup d'appels imbriqués 
                mMapValue[ xmlUsage->Id ] = szValue;;
        }
    } while ( ... );
    return 0;
}

Je pense que le probl�me vient des fonctions r�cursives, comme tu as dis.
Est ce qu'il y a une solution pour ce probl�me ?
Ce Thread permet d'actualiser les donn�es une par une.
Je ne sais pas si il y a une autre m�thode pour actualiser les donn�es que de faire du polling.
Je d�veloppe sous C++ builder.
Merci

30/08/2013, 17h00
oodini

Sous Visual, on peut changer la taille qu'on alloue � la pile, mais je ne sais plus comment.
30/08/2013, 17h09
ame_12

La fonction CreateThread a un param�tre o� on peut sp�cifier la taille de la pile, s'il est � z�ro, une taille par d�faut est prise.
le probl�me est que je ne sais pas si c'est �a le probl�me ni quelle taille prendre pour ne pas avoir de d�passement.
01/09/2013, 16h23
M�dinoc
G�n�ralement, il y a deux causes pour des Stack Overflow:
- Des tableaux tr�s volumineux en variable locale
- Un appel r�cursif infini.
Les d�bordements de pile suite � un appel r�cursif "trop profond" mais pas infini, en l'absence gros tableaux, �a n'arrive pratiquement jamais.

Note: il me semble que la pile fait 1MO par d�faut sous Windows.
01/09/2013, 18h43
koala01

Salut,

Personnellement, je ne suis pas fan de la solution qui consisterait � forcer la taille de la pile pour ton application.

La raison est que ton probl�me (le stack overfloaw) est le sympt�me qu'il y a "quelque chose qui ne va pas".

La seule chose que tu feras en modifiant la pile de ton application, c'est de "planquer la poussi�re sous le tapis".

Cela marchera maintenant, mais n'aura absolument pas r�solu le probl�me de fond et, t�t ou tarde, il reviendra en force.

De toute �vidence, tu manipules un fichier XML. La structure m�me du fichier xml fait que la "moins mauvaise solution" passe sans doute effectivement par la r�cursivit�.

Le probl�me de la r�cursivit�, c'est que chaque fonction qui en appelle une autre (m�me, et surtout si c'est elle que la fonction appelle), elle va placer des donn�es sur la pile, et que, t�t ou tard, la pile va d�border.

Plut�t que de jouer avec la taille de la pile, j'essayerais sans doute de trouver le moyen pour "simplifier" la structure m�me du xml utilis�, de limiter le besoin de r�cursivit�.

Cela peut entra�ner des changements profonds, et remonter sans doute jusqu'aux sp�cifications. Je comprendrai donc fort bien si tu me disais que l'option n'est pas envisageable.

Mais je reste cependant convaincu que c'est la seule option envisageable sur le long terme, car tes donn�es continueront � s'entasser, quoi que tu fasses ;)