Discussion :

[poukill]

Bonjour à tous,

J'ai actuellement un programme on ne peut plus simple qui utilise la bibliothèque de traitement d'image Vigra:

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
22
23
24
25
26
27
28
29
30
#include <iostream>
#include "vigra/stdimage.hxx"
#include "vigra/impex.hxx"

int main()
{
	try {

	vigra::ImageImportInfo info("C2.bmp");
        
	vigra_precondition(info.isGrayscale(), "please use grayscale image"); // Détection de contrat rompu...

         // create a gray scale image of appropriate size
        vigra::UInt16Image in(info.width(), info.height());
            
         // import the image just read
        importImage(info, destImage(in));

	}

	catch (vigra::StdException & e)
    {
        // catch any errors that might have occured and print their reason
        std::cout << e.what() << std::endl;
        return 1;
    }

	return 0;
}

En release, le programme compile et fonctionne parfaitement.
En mode débug, le programme compile et plante lamentablement sur

Exception non gérée à 0x10232c38 (msvcr80d.dll) dans test.exe :

La version débug de cette DLL est toute pourrie, ou bien c'est la bibliothèque qui ne gère pas bien le mode débug?

Si vous avez une explication, je suis très preneur, merci !

[Laurent Gomila]

Tu as de la chance : c'est en mode debug que ça plante, tu peux donc... debugger.
Ca plante sur quelle ligne ?

[poukill]

Oui je peux débugger, mais franchement ça donne rien du tout!
Ca plante sur la ligne en rouge (j'ai édité le post du dessus)

Exception de première chance à 0x10232c38 (msvcr80d.dll) dans test.exe : 0xC0000005: Violation d'accès lors de la lecture de l'emplacement 0xcccc0038.
Exception non gérée à 0x10232c38 (msvcr80d.dll) dans test.exe : 0xC0000005: Violation d'accès lors de la lecture de l'emplacement 0xcccc0038.
Exception de première chance à 0x10232c38 (msvcr80d.dll) dans test.exe : 0xC0000005: Violation d'accès lors de la lecture de l'emplacement 0xcccc0038.
Exception non gérée à 0x10232c38 (msvcr80d.dll) dans test.exe : 0xC0000005: Violation d'accès lors de la lecture de l'emplacement 0xcccc0038.

Quand je vais fouiller dans la pile des appels, le dernier bout de code avant le code machine est :

Code :

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

1
2
3
4
5
6
7
static int __CLRCALL_OR_CDECL compare(const _Elem *_First1, const _Elem *_First2,
size_t _Count)
{ // compare [_First1, _First1 + _Count) with [_First2, ...)
// _DEBUG_POINTER(_First1);
// _DEBUG_POINTER(_First2);
return (::memcmp(_First1, _First2, _Count));
}

Ca bloque sur la ligne en rouge dans "msvcr80d.dll", alors qu'avec la même DLL, version Release, ça passe! J'ai vu ça quand je vois le chargement des symboles...

[Jean-Marc.Bourguet]

Tu as bien verifie que les pointeurs sont valides?

[poukill]

Tu as bien verifie que les pointeurs sont valides?

Oui, puisque que ça marche en Release...
CE qui est marrant, c'est que mon bloc catch n'attrape aucune exception, j'ai le droit à une exception non gérée...
idem avec une std::exception (encapsulée dans la classe vigra::StdException e crois).

Je viens d'avoir une réponse par mail du créateur de la librairie:

Since the Properties of the Debug and Release
versions are independently set, it is not unlikely that I forgot
something in the Debug config (I almost always work with the Release
build -- the Debug is just too slow).

Comment est-ce possible?

Merci de votre coup de main.

[Jean-Marc.Bourguet]

Oui, puisque que ça marche en Release...

Ce n'est pas une preuve.

[loufoque]

CE qui est marrant, c'est que mon bloc catch n'attrape aucune exception, j'ai le droit à une exception non gérée...

C'est parce que les exceptions C++ et les exceptions de Windows c'est pas la même chose.

[poukill]

C'est parce que les exceptions C++ et les exceptions de Windows c'est pas la même chose.

Oui bien sûr, j'avais oublié...

Ce n'est pas une preuve.

+1

Tu as raison Jean-Marc

Voici mon bloc try:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
try {
vigra::ImageImportInfo info("C2.bmp");
// Pointeur non valide en Debug!!!!
        
vigra_precondition(info.isGrayscale(), "please use grayscale image");

// create a gray scale image of appropriate size
vigra::UInt16Image in(info.width(), info.height());
            
// import the image just read
importImage(info, destImage(in));

afficher(in);
}

Effectivement, en mode Debug, mon premier objet info n'est pas valide!
Pourtant, la configuration est la même. Là je suis perplexe.

Je vous écoute très attentivement là...

[Laurent Gomila]

Pas valide parce que le fichier n'a pas été trouvé ? Le répertoire de travail est-il le même en debug et en release ?

[poukill]

Exactement le même, comme d'habitude sur un projet Visual Studio...

[Laurent Gomila]

Exactement le même, comme d'habitude sur un projet Visual Studio...

J'aurais plutôt dit le contraire. Il en faut peu pour que le répertoire par défaut soit le répertoire de sortie (donc Debug en debug, et Release en release). je crois même que c'est ça par défaut si tu ne changes pas l'option qui va bien (directement le répertoire de travail, ou bien le répertoire de sortie).

[poukill]

Les répertoires de sortie sont différents effectivement : Debug en debug et Release en release...
Par contre, l'image "C2.bmp" est à côté des fichiers sources, c'est à dire dans le répertoire de travail commun aux deux!

J'ai fait des tests supplémentaires en mettant l'image directement à côté de l'exe dans le répertoire "Debug", ça ne change rien...

J'ai aussi recréer complètement le projet en laissant tout par défaut: le release marche directement, alors que le debug plante de suite...

J'y comprend RIEN!

[nicroman]

Ca ressemble beaucoup à de la mémoire non initialisée...
En mode debug, Visual remplit toute mémoire par un pattern précis. Si ce pattern est retrouvé à l'utilisation de la mémoire (memcmp, memmove, ...) hop... exception.
Ce n'est pas le cas en mode release... Comme l'allocation mémoire au processus se fait par page, tu peux très bien lire la page entière sans l'avoir allouée, et sans exception.

Je comprends pas bien par contre:

vigra::ImageImportInfo info("C2.bmp");
// Pointeur non valide en Debug!!!!

info n'est pas un pointeur ! l'objet est sur la pile donc forcément valide !

[JolyLoic]

Il en faut peu pour que le répertoire par défaut soit le répertoire de sortie (donc Debug en debug, et Release en release). je crois même que c'est ça par défaut si tu ne changes pas l'option qui va bien (directement le répertoire de travail, ou bien le répertoire de sortie).

Par défaut, du moins dans la version 2005, le répertoire de travail est égal au répertoire du projet (c'est à dire celui qui contient le .vcproj). Il est donc bien le même dans les deux cas.

Les exception windows sont effectivement différentes des exceptions C++, mais il y a des passerelles entre les deux, et avec les bonnes options de compilation, un catch(...) attrapera aussi les exceptions windows. En l'occurence, ça n'apprendra rien sur le problème, mais ça peut servir...

[poukill]

Ca ressemble beaucoup à de la mémoire non initialisée...
En mode debug, Visual remplit toute mémoire par un pattern précis. Si ce pattern est retrouvé à l'utilisation de la mémoire (memcmp, memmove, ...) hop... exception.
Ce n'est pas le cas en mode release... Comme l'allocation mémoire au processus se fait par page, tu peux très bien lire la page entière sans l'avoir allouée, et sans exception.

Ok, je savais pas.

Je comprends pas bien par contre:

info n'est pas un pointeur ! l'objet est sur la pile donc forcément valide !

Eh bien oui c'est vrai. C'est suite à la remarque de Jean-Marc que je me suis mis à parler de pointeurs, sans raisons ! ^^
L'objet est par contre mal "creer", car avec une watch dans Visual, je vois bien que juste après la première ligne:
* Mode Debug : Tous les champs de données de mon objet info sont vides
* Mode Release : Tous les champs sont corrects : noms de l'image, taille en x et y, etc.
En Debug, l'objet est bien créer mais invalide (comme si le constructeur n'avait pas fait son boulot, ou bien qu'il n'a pas trouvé le chemin de l'image)

Par défaut, du moins dans la version 2005, le répertoire de travail est égal au répertoire du projet (c'est à dire celui qui contient le .vcproj). Il est donc bien le même dans les deux cas.

Oui, c'est bien ça...
J'essaierai de mettre un catch(...) pour récupérer cette exception non C++. On verra bien!

Merci à vous.

[Laurent Gomila]

Ta bibliothèque ne te donne aucun moyen de récupérer une erreur plus précise ?

[poukill]

Ta bibliothèque ne te donne aucun moyen de récupérer une erreur plus précise ?

Non, pas que je sache. J'ai envoyé un mail à l'auteur de la bibliothèque concernant ce message, et voici ce qu'il m'a répondu:

Since the Properties of the Debug and Release
versions are independently set, it is not unlikely that I forgot
something in the Debug config (I almost always work with the Release
build -- the Debug is just too slow).

comme je l'avais déjà indiqué plus haut.
S'il y avait une astuce, je pense qu'il me l'aurai donné. Apparemment lui travaille toujours en release.

Je ne donne pas beaucoup plus d'infos, je suis désolé...

[nicroman]

N'ayant pas VStudio.Net sous les yeux, je vais pas être très précis...
Mais il existe dans les options de "Run" je crois, une entrée qui permet de règler comment les exceptions sont 'handlées' (y compris les exceptions C++, et/ou les exceptions Windows).
Déjà, perso, je met par défaut: "break if exception is not handled". En bref, si une exception est levée, mais n'est pas gérée dans un 'catch', le débugger va s'arrêter immédiatement.

Si tu as la librairie debug de vigra (dangereux comme nom ! ), tu peux entrer dans le constructeur et voir ce qu'il fait.

Sinon, pour ce qui est de la différence entre debug et release, elle ne devrait se résumer qu'à: virer toutes les optimisations (inlines, etc...) et rajouter les symboles.
La partie 'runtime' par contre, fait beaucoup plus de vérification (par exemple passage de uint32->uint8, vérification que toute la partie 'haute' est à 0, vérification de la mémoire à chaque memxxxxxxx, initialisation des pointeurs à 0xCDCDCDCD, ....).

Rien ne t'empeche, de compiler avec les options de debug ET d'utiliser la librairie runtime release... ou... l'inverse (qui est à mon avis l'option la plus interessante).