Crash depuis cet après midi.

Version imprimable

Salut, j'ai un crash depuis cet après midi, pourtant je n'ai pas modifié mon code depuis et ce matin ça marchait.

Voici ce que m'indique valgrind :

Code:

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
 
==11959== Invalid read of size 1
==11959==    at 0x4C2E0F4: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11959==    by 0x6486160: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==11959==    by 0x4523C8: odfaeg::network::Network::sendPbKey(odfaeg::network::User&) (in /home/laurent/Développement/Projets-c++/ODFAEGVIDEOTUTORIAL/bin/Debug/ODFAEGVIDEOTUTORIAL)
==11959==    by 0x44F575: odfaeg::network::SrkServer::checkMessages() (in /home/laurent/Développement/Projets-c++/ODFAEGVIDEOTUTORIAL/bin/Debug/ODFAEGVIDEOTUTORIAL)
==11959==    by 0x4330F1: odfaeg::core::Application::exec() (application.h:84)
==11959==    by 0x432E1A: main (main.cpp:4)
==11959==  Address 0xc278f50 is 0 bytes after a block of size 32 alloc'd
==11959==    at 0x4C2B800: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11959==    by 0x44AA48: odfaeg::network::AES_ENC::AES_ENC() (in /home/laurent/Développement/Projets-c++/ODFAEGVIDEOTUTORIAL/bin/Debug/ODFAEGVIDEOTUTORIAL)
==11959==    by 0x4312A8: _GLOBAL__sub_I_symEncPacket.cpp (in /home/laurent/Développement/Projets-c++/ODFAEGVIDEOTUTORIAL/bin/Debug/ODFAEGVIDEOTUTORIAL)
==11959==    by 0x4DF14C: __libc_csu_init (in /home/laurent/Développement/Projets-c++/ODFAEGVIDEOTUTORIAL/bin/Debug/ODFAEGVIDEOTUTORIAL)
==11959==    by 0x6C6FE54: (below main) (libc-start.c:246)
==11959== 
==11959== Conditional jump or move depends on uninitialised value(s)
==11959==    at 0x4C2E0F8: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11959==    by 0x6486160: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==11959==    by 0x452407: odfaeg::network::Network::sendPbKey(odfaeg::network::User&) (in /home/laurent/Développement/Projets-c++/ODFAEGVIDEOTUTORIAL/bin/Debug/ODFAEGVIDEOTUTORIAL)
==11959==    by 0x44F575: odfaeg::network::SrkServer::checkMessages() (in /home/laurent/Développement/Projets-c++/ODFAEGVIDEOTUTORIAL/bin/Debug/ODFAEGVIDEOTUTORIAL)
==11959==    by 0x4330F1: odfaeg::core::Application::exec() (application.h:84)
==11959==    by 0x432E1A: main (main.cpp:4)
==11959== 
client connected!
==11959== Jump to the invalid address stated on the next line
==11959==    at 0x3F800000: ???
==11959==  Address 0x3f800000 is not stack'd, malloc'd or (recently) free'd
==11959== 
==11959== 
==11959== Process terminating with default action of signal 11 (SIGSEGV)
==11959==  Access not within mapped region at address 0x3F800000
==11959==    at 0x3F800000: ???
==11959==  If you believe this happened as a result of a stack
==11959==  overflow in your program's main thread (unlikely but
==11959==  possible), you can try to increase the size of the
==11959==  main thread stack using the --main-stacksize= flag.
==11959==  The main thread stack size used in this run was 8388608.
==11959== 
==11959== HEAP SUMMARY:
==11959==     in use at exit: 2,448,804 bytes in 4,056 blocks
==11959==   total heap usage: 10,013 allocs, 5,957 frees, 3,926,877 bytes allocated
==11959== 
==11959== LEAK SUMMARY:
==11959==    definitely lost: 2,540 bytes in 14 blocks
==11959==    indirectly lost: 0 bytes in 0 blocks
==11959==      possibly lost: 18,759 bytes in 254 blocks
==11959==    still reachable: 2,427,505 bytes in 3,788 blocks
==11959==         suppressed: 0 bytes in 0 blocks
==11959== Rerun with --leak-check=full to see details of leaked memory
==11959== 
==11959== For counts of detected and suppressed errors, rerun with: -v
==11959== Use --track-origins=yes to see where uninitialised values come from
==11959== ERROR SUMMARY: 5 errors from 3 contexts (suppressed: 1 from 1)
Processus arrêté

07/04/2015, 19h19
Daïmanu

Bonsoir.

Sans code c'est difficile de dire ce qui cloche.
Mais dans le log, il est question de network, peut être le problème vient du réseau ?
07/04/2015, 20h27
koala01

Salut,

Heu, tu as pensé à la solution universelle : le débuggeur ???

Car, sans le code qui reproduit l'erreur, il sera difficile de te venir en aide.

Et, comme il s'agit d'un crash sauvage, j'aurais tendance à croire que tu fais encore de la semoule avec tes pointeurs, ce qui tendrait, en plus à faire en sorte que l'erreur réelle se trouve en réalité bien loin de l'endroit où le crash se produit ;)
07/04/2015, 20h45
Invité

Citation:

Salut,

Heu, tu as pensé à la solution universelle : le débuggeur ???

Car, sans le code qui reproduit l'erreur, il sera difficile de te venir en aide.

Et, comme il s'agit d'un crash sauvage, j'aurais tendance à croire que tu fais encore de la semoule avec tes pointeurs, ce qui tendrait, en plus à faire en sorte que l'erreur réelle se trouve en réalité bien loin de l'endroit où le crash se produit

Le débuggeur ne m'indique rien. (Il ne m'indique pas le nom de la fonction qui plante)
08/04/2015, 08h34
ternel

tu as bien compilé avec les informations de débug (-g pour gcc)?
08/04/2015, 09h23
Invité

Oui.
08/04/2015, 09h38
Iradrille

Si c'est compilé avec les infos de debug, il devrait être possible de récupérer la pile d'appels (?)
Çà ne te donnera pas forcément l'endroit de l'erreur, mais au moins l'endroit où elle est détectée, c'est un début.

Sinon, le crash est reproductible à 100 % ? Si c'est pas le cas, ça peut être un problème de threading ou de variable non initialisée.
Valgrind reporte une erreur (ou warning ?) la dessus, ça n'a peut être aucun rapport, mais ça vaut le coup d'y jeter un œil.
08/04/2015, 21h23
mintho carmo

Tu es génial, Lolilolight. http://www.developpez.net/forums/d15...tes-suspectes/
Quand tu as un bug avec ton code, tu penses en premier à une intrusion sur ton PC de quelqu'un qui a changé la lib C++ de gcc. :ptdr:
Pourquoi pas, quand on a un bug, il faut explorer toutes les pistes...
09/04/2015, 08h34
Invité

Pfff, j'en ai marre de votre mauvaise foi et de votre ingratitude, je n'ai même plus envie de vous répondre...

Quand on ne sait pas ce que je fais dans la vie, ni ce que je deviens, on se tais!
09/04/2015, 10h25
skeud

Salut, vais tenter de te filer un coup de main si tu veux bien :).

Déjà pourrais-tu poster le code de:

Code:

odfaeg::network::Network::sendPbKey

Apparemment tu as un invalid read dedans, qui conduit à un conditional jump, puis à un segfault.
Par contre tu n'as pas du compiler tout tes fichiers avec le debug (-g/-ggdb3 dans le CCFLAGS).
En faisant ça tu auras la ligne exacte qui pose problème.

Le fait que ça ne crash pas avant mais crash maintenant peut très bien dépendre de l'initialisation de ta mémoire, il suffit qu'un jour ta mémoire soit de bonne humeurs pour que ça marche et le lendemain non. :).
09/04/2015, 11h10
bacelar

Citation:

En faisant ça tu auras la ligne exacte qui pose problème.

Plus réalistement, la ligne où c'est parti en sucette, le problème peut être bien avant, malheureusement.

Lolilolight, ARRETES de faire ton Calimero, du code qui tombe en marche et qui arrête de fonctionne après un certain temps (passage aux multi-CPU, changement d'heure, passage d'un DEAL sur swap de taux sur emprunt avec plus de 1000 coupons trimestriels, etc...), c'est un truc qui arrive tout les jours (oui, les exemples sont du vécu, et même sur du code qui à vue passer des milliard et des milliards d'€ de transaction pendant plus de 15 ans et 2 migrations d'OS complètement différents).

Donc on enlève ces œillères et ces doigts du c., Lolilolight. :weird:
09/04/2015, 11h23
skeud

Citation:

Envoyé par bacelar

passage d'un DEAL sur swap de taux sur emprunt avec plus de 1000 coupons trimestriels

Kamoulox? :mouarf: :dehors:
12/04/2015, 13h59
Invité

J'ai dû perdre la mémoire, j'aurai dû deviner, c'était tellement évident!
12/04/2015, 17h38
the Hound

Citation:

Envoyé par Lolilolight

Pfff, j'en ai marre de votre mauvaise foi et de votre ingratitude, je n'ai même plus envie de vous répondre...

Le deuche du C++ :aie:

Personnellement quand je vois que tu as lancé/es intervenu sur un thread, je ne prends même plus la peine de lire le sujet ...
Parce qu'à chaque fois c'est la même chose, tu viens exposer un problème et quand les autres te proposent une solution, tu n'en prends aucunement compte. Ta solution est toujours la meilleure, et même quand au bout de trois pages de débat on réussit à prouver que t'es dans le faux, tu ne remets absolument pas ta façon de faire en question ... et c'est comme ça sur tous les threads que j'ai eu l'occasion de voir !
Sans compter que, sans vouloir t'offenser, tu m'as l'air d'avoir de sérieuses lacunes sur des connaissances très basiques et ça me semble important de le souligner puisque ce n'est absolument pas à l'avantage de ceux qui posent des questions sérieuses et que tu embrouilles avec tes réponses bancales (et rarement justes) ...

Alors ne t'étonnes pas si tu te mets à dos tous ceux qui veulent vraiment t'aider ... et c'est surement pas en les qualifiant d'ingrats que ça va arranger les choses ;)

Citation:

Quand on ne sait pas ce que je fais dans la vie, ni ce que je deviens, on se tais!

Ce que tu deviens je sais pas, par contre tu fais un framework pour jeux vidéo. Mais quand je vois le code que tu fournis et les soucis que tu rencontres ... je me dis qu'Unity3D c'est pas mal non plus :mrgreen:
13/04/2015, 11h07
Astraya

Hormis les trolls sur lolilolight....

Ton problème vient surement d'un dépassement mémoire modifiant trop loin.... et donc faisant crash une partie qui ne devrait pas planter.
Ce type d'erreur peut expliquer pourquoi un jour ça fonctionne et d'autre pas.. c'est de la chance... tout va dépendre de ou l'allocation est faite en mémoire. Et généralement visual studio alloue souvent au même emplacement dans son context (c'est facile à vérifié en debug, tu relances "F5" et tu auras la même adresse sur 2 exécutions différentes)

Il faut juste trouver les dépassements mémoire. (solutions : marquage des allocations (la plus cool et efficace) et Valgrind si tu veux utiliser des outils externes)
13/04/2015, 21h18
Invité

Oui, ça doit sûrement être ça le problème, bref, je vais y regarder...
14/04/2015, 14h31
Astraya

De rien...