plantage std::cout avec VS 2005

**globule71** · 05/04/2007, 20h44

Bon bah voil�, tout est dans le titre !
J'aimerai savoir si quelqu'un � rencontr� le m�me probl�me. Cela fait d�j� la seconde fois que �a m'arrive et pour la premi�re fois j'ai du refaire le projet � z�ro mais j'aimerai pouvoir �viter �a... Surtout que le projet est assez cons�quent.

Tout compile comme il faut. Mais lors de l'execution, le mode debug de l'exe se d�roule sans probl�me mais lorsque je compile en release et que j'execute l'application, celle-ci crash en pointant du doigt ntdll.dll...
Alors bon un plantage sur un cout comme celui-ci :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

std::cout<<"ssl ok"<<std::endl;

�a foue un peu les b***.

**mchk0123** · 05/04/2007, 22h04

Tu peux nous mettre le message d'erreur exact qui est affich� ?

**globule71** · 05/04/2007, 22h09

Exception non g�r�e � 0x7c911095 (ntdll.dll) dans ChgEtatPidiSoap_MFC.exe : 0xC0000005: Violation d'acc�s lors de l'�criture � l'emplacement 0x0044c948.

Mais je doute que �a vous �claire :s

**Laurent Gomila** · 05/04/2007, 22h13

Et avec le d�bogueur tu n'arrives pas � avoir plus d'informations concernant le contexte du plantage ? (tu peux garder tous les param�tres du mode Release et simplement changer l'option "g�n�rer les informations de d�bogage")

**lun4t1k** · 05/04/2007, 22h14

C'est n�cessaire de le r�peter le std::endl; ?
J'ai pas de probl�me, peut �tre le fais je machinalement!

**globule71** · 05/04/2007, 22h22

j'ai fait expr�s de ne pas utiliser le "using namespace std", au d�but je croyais � un conflit de namespace mais visiblement �a n'est pas le cas...
J'arrive � voir ou �a plante mais c'est tr�s bas niveau ...

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
void __cdecl _lock_file (
        FILE *pf
        )
{
        /*
         * The way the FILE (pointed to by pf) is locked depends on whether
         * it is part of _iob[] or not
         */
        if ( (pf >= _iob) && (pf <= (&_iob[_IOB_ENTRIES-1])) )
            /*
             * FILE lies in _iob[] so the lock lies in _locktable[].
             */
            _lock( _STREAM_LOCKS + (int)(pf - _iob) );
        else
            /*
             * Not part of _iob[]. Therefore, *pf is a _FILEX and the
             * lock field of the struct is an initialized critical
             * section.
             */
            EnterCriticalSection( &(((_FILEX *)pf)->lock) ); //plante ici ensuite on rentre ds ntdll.dll
}

Par contre �a parle de fichier... alors bon je sais qu'on utilise des stream en g�n�ral autant pour l'affichage � l'�cran autant que pour la gestion de fichier mais bon autrement je vois vraiment pas ou �a peut venir ...
J'ai peut �tre mis le doigt sur un bug de VS2005 :s

**globule71** · 05/04/2007, 22h27

Ah oui j'oubliais... la pile d'appel des fonctions :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
 
 ntdll.dll!_RtlEnterCriticalSection@4()  + 0x90 octets	
xxxxxxx.exe!_lock_file(_iobuf * pf=0x0044c924)  Ligne 238	C
xxxxxxx.exe!fputc(int ch=115, _iobuf * str=0x0044c924)  Ligne 46 + 0x6 octets	C
xxxxxxx.exe!std::basic_filebuf<char,std::char_traits<char> >::overflow(int _Meta=115)  Ligne 236 + 0xa octets	C++
xxxxxxx.exe!std::basic_streambuf<char,std::char_traits<char> >::xsputn(const char * _Ptr=0x0044c4a0, int _Count=6)  Ligne 379 + 0xd octets	C++
xxxxxxx.exe!std::operator<<<std::char_traits<char> >()  Ligne 762 + 0x18 octets	C++
xxxxxxx_MFC.exe!__tmainCRTStartup()  Ligne 318 + 0x12 octets	C

**Laurent Gomila** · 05/04/2007, 22h28

Ta ligne de code avec std::cout, elle se fait avant le main() ou dedans ? Si c'est avant, il est possible que la variable std::cout ne soit pas encore cr��e.

**mchk0123** · 05/04/2007, 22h31

Disons que tu as lev� un li�vre (mais peut �tre une simple illusion de bug).

Pour la compilation release + debug tu peux regarder ici : http://www.developpez.net/forums/sho...d.php?t=294724

Dis nous quand tu arrive � debugger ton programme en mettant un breakpoint sur ton cout.

EDIT : trop lent ;-)

**globule71** · 05/04/2007, 22h31

Dans le main() bien s�r ! Je rajoute que je programme en utilisant la librairie MFC en mode console.
En tout cas merci de m'avoir r�pondu si vite et de vous donner de la peine d'esseyer de r�soudre ce probleme

**mchk0123** · 05/04/2007, 22h34

Tu est sur que tu n'as pas d'autres "cout <<" en plus de celui dont tu nous parles ?

**globule71** · 05/04/2007, 22h36

Si j'ai en d'autres mais plus bas ds le code... en fait �a plante d�s le premier cout qu'il rencontre

J'arrive � debugger en release... mais c'est tr�s dur � suivre, �a part dans une gestion de mutex et je vois vraiment pa.s pourquoi �a plante !

**mchk0123** · 05/04/2007, 22h42

Ton _lock_file �a me fait penser � bug dur � cuire que j'ai d�j� eu.
C'�tait avec des fichiers (et pas de stream console), mais bon.
J'essayais de faire un simple fopen() & fwrite() qui plantait joliement avec un message identique au tien sous VC 6. Tout simplement parce que j'avais une deuxi�me instance de mon programme qui avait plant� (mais tournais encore sans que je le vois), donc fichier lock� violement. D'ou pb avec fopen().

Essaye de voir c�t� gestionnaire de processus si y a pas un proc � killer.
Sinon reboot.

**globule71** · 05/04/2007, 22h45

ben... je t'avouerai que le premier pb... c'�tait pas vraiment un cout, mais c'�tait aussi bizard, �a arrivaut au m�me point et c'etait justement sur la gestion de fichier mais ici j'ai beau rebooter �a me fait la m�me chose.
Alors � moins que le process reste vivant � chaque red�marrage...

**Laurent Gomila** · 05/04/2007, 22h49

Il y a quoi entre le d�but du main() et l'instruction qui plante ? Tu peux essayer d'�liminer les trucs inutiles pour cibler au maximum le probl�me ?

**mchk0123** · 05/04/2007, 22h49

Ton programme il est cens� faire quoi (c'est pas un driver j'esp�res ...

).

Pour les processus, apr�s un reboot il ne reste rien (sauf si install� comme devant d�marrer au lancement de Windows).

**globule71** · 05/04/2007, 22h54

Mon appli est un client gsoap... marche tr�s bien en debug, j'ai d�j� compil� un autre client qui marche tr�s bien en release mais quand je dis que je soul�ve peut �tre un bug de VS2005 je pense que je ne dois pas en �tre tr�s loin ...
Apr�s est ce que des options de compilations peuvent le faire planter aussi violemment, �a j'en sais rien du tout. J'ai pas trop touch� � ces options (juste link� la biblio en statique, utilis� le noyau de debuggage MT (avec les librairies qui vont avec ...)

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
	int nRetCode = 0;
	std::cout<<"Attention ça va encore planté ici :/"<<std::endl;
....
 
//ben en effet ça plante encore...

Et avant le main(), juste des d�finition de fonctions n'utilisant pas de cout mais des std::string.

**Laurent Gomila** · 05/04/2007, 22h58

Est-ce que ce code seul plante ? Si non, qu'est-ce qui change par rapport au tien ? Tu as des variables globales ou membres statiques quelque part ?

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
#include <iostream>
#include <windows.h>
 
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
    std::cout << "Attention ça va encore planter ici :/" << std::endl;
    return 0;
}

**globule71** · 05/04/2007, 23h06

Bon j'ai comment� toutes les definitions de fonctions ainsi que tout le reste du code en aval du main et l� en effet �a plante plus...
Me reste plus qu'� decommenter petit � petit... Enfin je trouve �a quand m�me bizard, �a a peut �tre un lien avec l'utilisation de la classe std::string mais lequel... reste � voir !

edit : En ractivant la d�finition de ma fonction log qui utilise des fstream (tient donc !?) �a me refait un joli plantage ! Je continue mes investigations ...

to be continued...

**mchk0123** · 05/04/2007, 23h17

Cherches pas c'est un lock (bas niveau) quelconque dans ta fonction de log.
Pour chaque sortie sur cout, VS peut faire un verouillage de la resource console (�a reste � v�rifier).

Elle peut tr�s bien marcher 99% des fois qu'elle est utilis�. Et si par malheur le flux des messages sortant devient trop dense (car le programme tourne plus vite en Release), ... patatraque ... il se bloque.

Sans compter que si tu est en MT, cela n'arrange pas tes affaires.

Essaye de mettre un appel � sleep() quelque part pour ralentir le d�bit dans la log. Et tu verra que tu n'as plus de bug.

C'est une faille dans ta conception. Et pas un bug de VS++.

plantage std::cout avec VS 2005

Visual C++

Discussions similaires

Partager

Partager