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