Discussion :

[jimmplan]

Bonjour,
Je maintient un logiciel développé avec C++ (MFC).

Depuis une semaine les utilisateurs du logiciel mon retournés 4 crash identique que je ne suis pas capable de résoudre.

Ils disent que la journée finie il sauvegarde le projet puis le lendemain lors de l'ouverture du projet, le programme crash !!!

Ils m'ont envoyé les fichiers qui crash et effectivement 2 erreurs fatales surviennent lors de l'ouverture du fichier.
Voici le détail du premier fichier :

Signature de l'erreur ------------------------------------------
AppName: MonApp.exe AppVer: VersionDeMon App ModName: unknown
ModVer: 0.0.0.0 Offset: 00000002


Lorsque je clique pour plus d'info :

Exception Information
Code: 0xc0000005 Flags: 0x00000000
Record: 0x000000000000000 Address: 0x0000000000000002

Par la suite j'ai de l'infos sur toute mes modules.

Voici le détail de la deuxième erreur fatale :

Signature de l'erreur ------------------------------------------
AppName: MonApp.exe AppVer: VersionDeMon App ModName: ntdll.dll
ModVer: 5.1.2600.2180 Offset: 00043345


Lorsque je clique pour plus d'info :

Exception Information
Code: 0xc0150010 Flags: 0x00000001
Record: 0x000000000000000 Address: 0x000000007c953345

Puis le modules...


Est-ce que vous pouvez m'apporter de l'aide sur ce problème ?

Merci et bonne fin de journée

Jimmy Plante

[hiko-seijuro]

N'cha,

le problème est que l'on ne comprend rien a ton erreur car nous ne sommes pas windows ou microsoft

Il faut que tu debugges ton programmes et nous montrer la portion de code incriminée

[jimmplan]

l se trouve que ca plante dans le code MFC que je n'ai pas access (Si ce n'est qu'en assembleur)...
Je voulais juste savoir si quelqu'un a déja de quoi de semblable ?!?
Merci....

PS: je ne suis pas devant mon code présentement... je vais quand meme essayer de mettre du code pour vous aider...

Merci
Bye
Jimmy Plante

[farscape]

salut,
ça plante dans le code mfc parce que l'appel initial est erroné.
si tu appels une méthode d'un objet par un pointeur nul l'erreur est bien dans le code MFC, mais l'erreur c'est que le pointeur est null...
remonte la pile des appels jusqu'à ton code (en mode debug).

[3DArchi]

Exception Information
Code: 0xc0000005 Flags: 0x00000000
Record: 0x000000000000000 Address: 0x0000000000000002

Ici, il s'agit d'une STATUS_ACCESS_VIOLATION sur l'adresse 0x0000000000000002. En gros, t'as du appelé une méthode avec un pointeur NULL ou quelque chose de ce goût là.

Exception Information
Code: 0xc0150010 Flags: 0x00000001
Record: 0x000000000000000 Address: 0x000000007c953345

Un problème olé olé?

[bacelar]

Il semblerait que jimmplan nous donne des extraits d'un fichier de log de DrWatson.
Si c'est la cas, il connait peut-être les dumps et WinDbg et comment les créer sur le terrain (chez le client final).

Si, il arrive à le reproduire chez lui et pas uniquement sur le terrain (chez le client), il aura accès à la pile d'appel lors du plantage. Les MFC sont livrés avec les sources et avec les pdb dans la distribution de VS. S'il n'a pas accès aux sources des MFC lors d'un plantage dans les MFC, ou il n'a pas installé les sources des MFC lors de l'installation de VS, et c'est mal, ou l'environnement VS est mal configuré car il ne trouve pas les pdb des MFC.
Lors du lancement du programme dans le débugger, il affiche "symbols loaded" à la fin de la ligne indiquant le chargement de chaque dll quand il trouve le pdb correspondant à la dll. Normalement cela devrait être le cas pour les MFC, si l'environnement VS est correctement configurer.

Si tout est bon, jimmplan pourra nous envoyer la ligne dans les MFC qui plante ainsi que la pile d'appel.

Mais juste avec les informations qu'il nous a transmis, on peut déjà dire que c'est un pointeur à NULL qui est utilisé car l'adresse 0x0000000000000002 fait partie des 64 premier ko de l'espace d'adressage du programme qui est interdit en lecture écriture, justement pour que les accès à des pointeurs NULL sous immédiatement détectés.

[jimmplan]

Bonjour, voici l'avancement de mon problème

Premièrement, merci de votre généreuse aide !

Deuxièment, voici quelques informations peut-être importante à vous dire concernant le logiciel que je maintient :

C'est un logiciel qui serialize le data et qui crée différent fichiers.
Une lacune que j'ai remarquée hier est que le comportement est différent entre double cliquer directement sur le fichier et ouvrir le programme + ouvrir le fichier.

Ce comportement m'a permis de comprendre d'ou provenait les deux erreurs que je vous ai mentionnés hier. Lorsque je double cliquais directement sur le fichier une premiere erreur m'apparaîssait (je ne vous l'ai pas mentionné hier) @Format de fichier inattendu@. (Cette erreur nous apparait lorsque nous essayons d'ouvrir un fichier avec un version moins récente que la sauvegarde.) Par la suite les deux erreur fatales m'apparaissaient. Ces deux erreurs fatales étaient dues ont fait que le programme oubliait d'initialiser deux variables.... Ces deux erreurs m'apparaisaient pas lorsque j'ouvrais le programme puis le fichier car à l'ouverture du programme nous créons toujours un fichier vide mais pas lorsque nous double-cliquons directement sur le fichier.

Bref, j'ai fixé les deux erreurs fatales que j'ai mentionnées hier... Cependant il me reste l'erreur anormal @Format de fichier inattendu@.

Cette erreur est trappée (catch) dans une la classe MFC (list_o.cpp) dans la serialization :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
DWORD_PTR nNewCount = ar.ReadCount();
CObject* newData;
 
while(nNewCount--)
(
   ar >> newData;
   AddTail(newData);
)

elle est trappé justement au >>...


Je sais pas si quelqu'un pourrais m'aider sur ce point...

Encore une fois, Merci
Jimmy Plante

[bacelar]

Ma remarque ne sera pas très constructive mais la gestion des versions sur les objets sérialisés avec les MFC, ça a toujours été la galère et je l'ai toujours esquivé.
Maintenant, avec l'XML, c'est bien plus ouvert et facile.

[jimmplan]

Merci quand même... Si le programme serait à recommencer j'aurais beaucoup de choses à changer mais bon rendu là ... ca fait 7 ans qu'il fonctionne auprès de l'entreprise et contient plus de 15 000 fichiers...

[farscape]

Ma remarque ne sera pas très constructive mais la gestion des versions sur les objets sérialisés avec les MFC, ça a toujours été la galère et je l'ai toujours esquivé.
Maintenant, avec l'XML, c'est bien plus ouvert et facile.

quand on sait comment ça fonctionne ça n'a rien de compliqué et c'est très puissant...
pour infos voir mon dernier article sur le sujet:
http://farscape.developpez.com/Artic...ationBoostMFC/

Apparemment ton problème vient sur la lecture d'une CList.
ce genre d'erreur arrive si par exemple il y a plusieurs versions du fichier et que la gestion des versions n'a pas été implémentée dans la méthode de sérialisation, du coup tu risques d'être décalé sur les données lors de la lecture.
tu obtiens dans ce cas le type de problème que tu signales...

[jimmplan]

Apparemment ton problème vient sur la lecture d'une CList.
ce genre d'erreur arrive si par exemple il y a plusieurs versions du fichier et que la gestion des versions n'a pas été implémentée dans la méthode de sérialisation, du coup tu risques d'être décalé sur les données lors de la lecture.
tu obtiens dans ce cas le type de problème que tu signales...

Humm cette voie m'intéresse beaucoup, pourrais tu developper ?
En fait moi en tant qu'analyste programmeur, je n'ai pas acces directement avec les usagers... Ils sont 150 et travaillent en Romanie ! Mais en fait il faut vivre avec leur manière de travailler qui n'est pas toujours adéquat....

Et il se pourrait qu'il aille fait des copier/coller/transferer à d'autres usagés etc ? Est ce que tu parle de ca ? Qu'est-ce que la gestion des versions ? (Le nSchema, ca ont le fait)...


Y a t'il moyen de savoir quelle classe est en erreur (mal sérialisée).
Y a t'il moyen d'ouvrir le fichier quand même sans les objets et leurs décendence ?

En fait ces 4 fichiers représente beaucoup d'heures ressources pour la compagnie, c'est pour ca qu'ils veulent que j'investige plus ...
On a espoir de récupérer les fichiers mais au moins de trouver la cause pour ne plus reproduire ce bug !

Merci pour ton aide

Jimmy Plante

[farscape]

je dis simplement que ça arrive si le versionning est mal géré :
une donnée est lue dans le programme mais n'est pas présente dans le fichier
le flux est décalé et tu tombes en erreur sur la lecture de la CList qui attend encore une ligne à lire ...
ce qui correspond à l'erreur signalée par les MFC.

[jimmplan]

Ok et as tu des moyens, des manières de contourner ca (Réparer le fichier)... du pas à pas, ...? Ou est-ce tout simplement impossible ?

Merci

Jimmy Plante

[farscape]

tu peux effectivement debugger pas a pas pour éventuellement constater et repérer le décalage.
tout va dépendre de la complexité de ta serialisation.
tu peux mettre un point d'arrêt dans toutes les méthodes serialize.
si le versionning est mal géré pour ce cas tu peux éventuellement trapper l'erreur avec un catch...
exemple:

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
 
template<class TYPE>
void MyTemplateListContainer<TYPE>::Serialize(CArchive& ar)
{
    m_bErrorInOut=false;
    CObject::Serialize( ar );
    if(!ar.IsStoring()) DeleteAll();    
    try
    {
        m_Array.Serialize( ar);        
    }
    catch( CException* e )
    {
        // Handle the exception here.
        // "e" contains information about the exception.
        m_bErrorInOut=true;
        OnError(!ar.IsStoring());
        e->Delete();
    }
}

ça te permettrai de détecter l'erreur, de la a relancer la serialisation en tenant compte de l'erreur il n' y a qu'un pas a faire...
ce n'est pas très propre, tout dépendra de la gravité de la situation...

[jimmplan]

Ok Donc a chacune des mes classes ayant la sérialisation j'ajouterai un try and catch... je mettrai un break point dans le catch donc je saurai quel objet fait défaut....

En espérant que cette méthode me permettra de réparer le fichier car j'ai plus de 200 classes à modifier ...

Merci, je vous redonne des nouvelles !

Jimmy Plante

[jimmplan]

Je suis en train de me demander si cette méthode me permettra de trouver l'objet corrompue... ? Je sais que c'est lorsque ar >> newData, ceci appel ReadObject de CArchive. Dans cette fonction parfois le readclass me retourne une CRuntimeClass à NULL et un peu plus loin une condition dit que si la ce CRuntimeClass est à NULL + if(obTag > (DWORD) m_pLoadArray->GetUpperBound) et bien Format du fichier invalide ....

?

Pense tu qu'avec le try and catch je pourrais trouver mon objet corrompue ?

Merci

[farscape]

tu trouveras le crash sur l'objet causant un problème , mais peut être que celui aura été causé par une lecture qui n'était pas prévue par un des objets précédents...