Problème d'allocation mémoire C++ / OpenCV

Bonjour

j'ai cherché à résoudre mon problème toute la nuit et je ne trouve pas de solution; Voici le message d'erreur :

"Erreur de segmentation (core dumped)"

Voici la fonction qui fait bugger à l'execution.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Mat BlurringFBA (Mat vfft) { int i=0, j=0; int n = vfft.rows; int m = vfft.cols; Mat win(n, m, CV_32FC1); Mat wout(n, m, CV_32FC1);   for (i=0;i<n;i++) for (j=0; j<m; j++) { Vec3b v = vfft.at<Vec3b>(i,j); v[0] =1/3*( fabs(v[0]) + fabs(v[1]) + fabs(v[2])) ; win.at<double>(i,j)=v[0]; } double var = min(m,n)/50; GaussianBlur(win, wout, Size(3,3) , var, var); return wout; }

---

cette fonction est appelée plusieurs fois dans le main() mais à l’exécution, elle s'appelle une fois et plante ensuite, avant même d’être rappelée, pour preuve, malgré :

Code:

---

1 2 3 4

Mat w1 = BlurringFBA (vfft1); cout<<"hello"<<endl; Mat w2 = BlurringFBA (vfft2);

---

l'affichage de "hello" ne se fait pas sur le terminal.

Quelqu'un peut-il m'expliquer comment éviter ce genre de plantage et me donner une solution dans ce cas précis ?

Merci

Salut,

Pour déboguer, l'affichage de message n'est pas du tout recommandé. Surtout pour une erreur de segmentation.

Connais-tu un débogueur? (GDB ou autre).

Sinon, je suppose que ton erreur vient d'ici:

Code:

---

double var = min(m,n)/50;

---

Ta variable doit sans doute toujours être initialisée à 0: tu divises 2 entiers.

Bonjour

Merci pour votre réponse.

Le debugger GDB me renvoie ceci après le bt :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#0 0x00007ffff6a1fcc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff6a230d8 in __GI_abort () at abort.c:89 #2 0x00007ffff7024535 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x00007ffff70226d6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x00007ffff7022703 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #5 0x00007ffff7022922 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #6 0x00007ffff70741a7 in std::__throw_logic_error(char const*) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #7 0x00007ffff707f9b1 in char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #8 0x00007ffff707fd48 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #9 0x0000000000401832 in main (argc=1, argv=0x7fffffffdfb8) at Main.cpp:75

---

j'ai modifié mon code en écrivant :

Code:

---

1 2	double var = min(double(m), double(n))/50;

---

Mais l'erreur persiste...
et je n'ai pas le bagage info pour interpréter le diagnostique du GDB...

Merci

Vu que l'erreur provient de la ligne 75 de Main.cpp sur la construction d'une std::string, j'ai des doutes que double var = min(double(m), double(n))/50; soit impliqué. :roll:

La ligne 75 correspond au début du main(). Ce sont des importations d'images couleur qui semble parfaitement fonctionner.

Code:

---

Mat vtild1 = imread(argv[1], CV_LOAD_IMAGE_COLOR);

---

Que signifient les autres lignes du diagnostique ?

Merci

Vérifies-tu que argv[1] existe? (avec argc). C'est tout bête mais quand on débute, on a très souvent ce genre d'erreur.

essai ca si tu n'es pas a l'aise avec GDB, mais il faudrait que tu apprennes a l'utiliser c'est plus pratique que des printf de debug :

Code:

---

1 2 3 4 5

if (argv[1]) Mat vtild1 = imread(argv[1], CV_LOAD_IMAGE_COLOR); else printf("arg[1] est NULL donc forcement ca risque pas de marcher\nNombre d'argument = %d\n", argc);

---

EDIT : oups j'ai tellement pas l'habitude de voir des fonctions hors classe en cpp que j'ai repondu en C :mouarf:

Code:

---

1 2 3 4 5 6 7 8

if (argv[1]) Mat vtild1 = imread(argv[1], CV_LOAD_IMAGE_COLOR); else { std::cout << "arg[1] est NULL donc forcement ca risque pas de marcher" << std::endl; std::cout << "Nombre d'argument = " << argc << std::endl; }

---

Tester une variable qui n'existe pas c'est le meilleur moyen de crasher.. :weird:
A moins que ton appel à main se termine toujours avec un paramètre NULL comme dans d'anciennes interfaces C ? J'en sais rien, par défaut j'en doute.
Comme dit plus haut, il existe argc pour vérifier cela.

Si tu fais :

if (argv[1]) tu testes l'existance de argv[1] c'est equivalent a if (argv[1] != nullptr) ya aucune raison que ca plante, si argv[1] existe on entre dans le corps du if, sinon argv[1] est nul donc on y entre pas

Et si argv est un tableau de taille 1?

Donc on teste argc.

Ba si il est de taille 1 argv[1] n'est pas defini donc ca rentre pas dans le if.. Je suis bien d'accord que ca fonctionne tres bien en utilisant argc mais cette methose fonctionne aussi

Effectivement, si argv est de taille 1, argv[1] n'est pas défini, mais il n'est pas nul pour autant, tu vas très certainement rentrer dans ton if avec un pointeur invalide, c'est un des jolis undefined behaviour hérités du C

Citation:

---

Envoyé par nibors

Ba si il est de taille 1 argv[1] n'est pas defini donc ca rentre pas dans le if.. Je suis bien d'accord que ca fonctionne tres bien en utilisant argc mais cette methose fonctionne aussi

---

On est en C++, pas en LUA. :calim2:

Btw, argv contient toujours au moins 1 élément, le nom du programme lancé, et finit par un 0 http://en.cppreference.com/w/cpp/language/main_function
Mais tester argv[1] ainsi reste une très mauvaise pratique. Ce n'est pas ainsi qu'on test les limites d'un tableau.

Citation:

---

Envoyé par dragonjoker59

Effectivement, si argv est de taille 1, argv[1] n'est pas défini, mais il n'est pas nul pour autant, tu vas très certainement rentrer dans ton if avec un pointeur invalide, c'est un des jolis undefined behaviour hérités du C

---

Au lieu de te baser sur des "tres certainement" tu devrais plutôt tester et te rendre compte par toi meme que ca marche ;)

Mea culpa.

Je me suis basé sur les tableaux classiques pour répondre.

Citation:

---

Envoyé par Bousk

On est en C++, pas en LUA. :calim2:

Btw, argv contient toujours au moins 1 élément, le nom du programme lancé, et finit par un 0 http://en.cppreference.com/w/cpp/language/main_function
Mais tester argv[1] ainsi reste une très mauvaise pratique. Ce n'est pas ainsi qu'on test les limites d'un tableau.

---

Premierement je n'ai jamais touché a du LUA donc je ne comprend pas ta comparaison désolé:mrgreen: .

Deuxiemement, evidement que tester argv[1] de cette maniere n'est pas propre (meme si cela fonctionne) mais on a ici a faire a un debutant en cpp (dans le bon sens du terme, ce n'est pas péjoratif :) ) et mon exemple avait pour but de mettre en évidence ce qui pose probleme avec un petit std::cout bien explicite lui montrant ce que ne va pas :mouarf:

Non mais le truc c'est que tu racontes un peu n'importe quoi

Citation:

---

Envoyé par nibors

Ba si il est de taille 1 argv[1] n'est pas defini donc ca rentre pas dans le if..

---

si argv[1] n'est pas défini ça fait n'importe quoi et c'est indéterminé. Et ça n'a surtout absolument aucune raison d'être évalué à false pour le if et donc de ne pas y rentrer. :calim2:

Et à fortiori un débutant on lui apprend les bonnes pratiques, l'utilisation de argc, et non un hack qui fonctionne uniquement dans un cas particulier.

Citation:

---

Et ça n'a surtout absolument aucune raison d'être évalué à false pour le if et donc de ne pas y rentrer.

---

Bin si, dans le monde des bisounours où le chargeur de l'OS n'a jamais l'idée, complètement saugrenue, de mettre le tableau des paramètres argv de main en limite de page mémoire, bin sinon => segfault dans les dents.
LOL :ptdr:

Citation:

---

if (argv[1] != nullptr) ya aucune raison que ca plante

---

Putain, je veux le même chargeur de programme pour Noël, enfin un qui met toutes les cases adressables par le programme à 0 avant de commencer, et un OS qui remet toujours des 0 dans la pile après dépilage.
Heu, c'est quoi ne nom de ton OS : bisounours-Linux ? :weird:

Euh, la norme de dit-elle pas que argv[argc] existe et est un pointeur nul?

(vérifie...)

Edit: Oui, c'est dit (n3290 (C++11 draft), section 3.6.1 - basic.start.main, verset 2: "The value of argv[argc]shall be 0."), par contre, la norme ne dit pas du tout que argc n'est jamais nul.

En revanche, il est possible que des normes comme POSIX garantissent de toujours remplir argv[0] avec le nom du programme tel qu'invoqué (garantissant donc que argc soit strictement positif), mais je ne trouve pas confirmation (ma source principale de référence sur le standard POSIX ne semble pas avoir de page pour main()).

Citation:

---

Envoyé par bacelar

Bin si, dans le monde des bisounours où le chargeur de l'OS n'a jamais l'idée, complètement saugrenue, de mettre le tableau des paramètres argv de main en limite de page mémoire, bin sinon => segfault dans les dents.
LOL :ptdr:


Putain, je veux le même chargeur de programme pour Noël, enfin un qui met toutes les cases adressables par le programme à 0 avant de commencer, et un OS qui remet toujours des 0 dans la pile après dépilage.
Heu, c'est quoi ne nom de ton OS : bisounours-Linux ? :weird:

---

Au lieu de faire le kéké et de prendre les gens de haut tu refflechie 2 sec (2 sec c'est pas long tu vas y arriver j'espere je pense) , argv est terminé par null (un petit tour sur cpp reference : ARGV: Pointer to the first element of an array of pointers to null-terminated multibyte strings), argv[0] contient le nom du prog (Nan sans dec 8O ?) donc soit le prog est executé sans arg et argv[1] est null, soit avec un ou plusieurs arg et argv[1] vaut ba le premier arg. Au mon Dieu et tout ca sans bisounours, juste en lisant la norme cpp c'est fou ça :ptdr:.