Discussion :

[FabaCoeur]

Bonjour,

Problème qui me fait très mal à la tête là... vraiment du mal à comprendre !
Je travailles sous Code::Blocks sur une application threadée. Quand je lance mon application sous Code::Blocks par "Build & run" tout se passe bien.

En revanche, quand je vais dans le dossier "bin/Debug/" pour lancer le compilé "à la main" en cliquant sur l'exe il y a un problème qui fait planter (visiblement problème de mémoire) le programme alors que l'exécutable est strictement le même !

J'ai ciblé le problème, il viendrait du passage d'argument au thread.
Voici un extrait en gros du programme:

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
 
void mafunction() {
while(...) {
 
        struct InfosClient info_client = malloc(sizeof(InfosClient));
 
        info_client->mon_int = i++; // i variable de la boucle incrémentée
        info_client->unpointeur = monptr; // pointeur constant
 
        // On créer un canal de communication avec ce client
        pthread_create(&info_client->thread, NULL, thread_client, info_client);
 
}
}
 
// Ouvre une communication avec le client
void* thread_client(void* arg) {
 
    InfosClient* infos = (InfosClient*)arg;
 
    printf("Int = %d\n", infos->mon_int); // Entier non incrémenté !
 
    printf("Int2 = %d\n", infos->unpointeur->unevaleur); // plante !
 
    return NULL;
}

J'ai testé d'afficher les adresses de "infos" et "info_client" dans les deux, il s'agit de la même adresse. Il faut alors croire qu'il y a quelque chose qui dénature les valeurs au passage...?

J'ai pensé à un problème de malloc mais l'adresse des pointeurs change à chaque fois, il y a donc bien allocation.

Puis aussi savoir surtout pourquoi ca plante quand je lance à partir de Code::Blocks tout fonctionne nickel et pourquoi quand je lance par le compilé ?!

Merci !

[LittleWhite]

C'est une supposition :

Charge tu un fichier de donnée , ou n'importe quoi.
Car lorsque code::blocks lance un programme , il lance le même que celui que tu as dans le dossier Debug , mais pas à partir du dossier Debug. ( je crois à partir du dossier projet ).
Ce que je veux dire, si tu utilise des données externes ( fichiers de données ), tu as du les mettres dans le dossier du projet. Donc Code::Blocks quand il lance ton programme , ton programme trouve les données.
Par contre en lançant ton programme à partir du dossier Debug, ton programme ne retrouve plus les fichiers de données qui lui faut -> Plantage

( Si c'est le cas, tu devrais revoir un peu la conception du chargement des fichiers )

Ceci était une supposition.

L'autre possibilité , c'est que dans l'envirronement de code::blocks , pour une raison x ça plante pas, et que lorsque tu lance directement ton executable, n'ayant plus l'envirronement de code::blocks , il plante.
Code::blocks , dans ce cas la "protege" du plantage , mais alors ton code à un problême.

[FabaCoeur]

Je ne charge aucune source externe.

Pour ce qui est de l'environnement tu as raison, quand tu lances avec CB il le lance à partir de la racine du projet, et pour preuve j'ai du copier/coller une DLL dans le dossier Debug (dll des threads nécessaire qui est présente à la racine du projet).

Le code est bon, puisque lorsque je la lance depuis CB il n'y a aucun plantage. Et tout semble fonctionner pour le mieux, par exemple l'entier qui doit n'incrémenter le fait très bien une fois lancé par CB. Lancé en externe, il n'incrémente de 0 à 1, puis reste bloqué à 1 par la suite... c'est à ne rien y comprendre !

D'autres idées ?
C'est sûr que ca doit provenir de l'environnement CB, mais bon il s'agit d'une application relativement simple ne faisant appel à aucune source externe...

[matafan]

C'est :

Code :

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

struct InfosClient *info_client = ...

et pas :

Code :

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

struct InfosClient info_client = ...

Edit : et ce n'est pas parce que ton code fonctionne dans certains cas qu'il est bon... Il y a plein de bugs qui ne se voient pas forcément, suivant où la mémoire est allouée, comment les variables sont initialisées... Il est relativement courant d'avoir des programmes qui plantent, mais qui ne plantent plus lorsqu'ils sont lancés dans un debugger par exemple.

re-edit : en fait ton code est peut-être correct si tu as

Code :

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

typedef struct InfosClient *InfosClient;

Mais dans ce cas, félicitation pour le choix judicieux des nom de types, et les mélanges structure/pointeur.

[FabaCoeur]

Oui en réalité j'ai fait un typedef, mais dans mon exemple j'ai oublié de mettre l'étoile (j'ai pas copié/collé mais tappé à la main).

J'ai continué à développer mon application en fesant abstraction de ce problème, et là je me rends compte que l'appli marche désormais si je les lance depuis le répertoire de debug.

Donc voila sur ce coup j'ai vraiment pas capté.
Désolé du topic inutile... merci quand même pour vos réponses

[FabaCoeur]

J'ouvre ce topic à nouveau car j'ai à nouveau le même problème.
Le comportement de l'application occasionne un plantage s'il n'est pas lancé par CB.

Je pose à nouveau ma question:
Quel facteur d'environnement fait qu'il n'est pas possible de lancer l'application directement par l'exécutable mais uniquement par le Run de CB ?

[droggo]

Hai,

Et on peut te répéter : ton programme "tombe en marche" quand tu le lances sous CB.

[LittleWhite]

Euh toujours, ton programme à un problème avec la mémoire ..... ( pointeurs, alloctions, ... )

Ou alors, fait un rebuild complet avec C::B

Je ne vois vraiment plus d'autre solution ...

[FabaCoeur]

J'ai déjà essayé le rebuild.
Le problème doit être d'une autre source.
Je réouvrirai le topic si je trouve la cause du problème.

[souviron34]

Euh toujours, ton programme à un problème avec la mémoire ..... ( pointeurs, alloctions, ... )

Absolument..

Fuite de mémoire, écrasement, dépassement..

C'est en général le cas si un programme plante tout seul, mais pas dans un débugger, ou lancé par autre chose, ou s'il suffit d'ajouter un print pour que ça marche (pas).

[LittleWhite]

Absolument..
..., ou s'il suffit d'ajouter un print pour que ça marche (pas).

Lorsque je commençais l'apprentissage du C , j'appelais ça une erreur de segmentation qui bouge. ( Ce qui n'est pas exactement la réalité )
Programme qui plante à une telle ligne , si on rajoute un printf , il plante trois lignes plus loin. ...
Je crois que c'est ce qu'il y a de pire à voir. Mais bon , un peu de logique, et un debuggeur + une feuille de papier , et le problème est résolu

[Emmanuel Delahaye]

J'ai déjà essayé le rebuild.
Le problème doit être d'une autre source.
Je réouvrirai le topic si je trouve la cause du problème.

Ton code a un bug, c'est tout. Poste le.

[FabaCoeur]

Le problème c'est que maintenant le code fait 60Ko pour 20 fichiers, et il s'agit d'une application ayant un coté client et serveur. Donc avant de poster tout le code je vais quand même continuer à essayer de plus cibler le problème pour pouvoir poster un bout de code plus réduit que tout le projet.

EDIT: Bon bah en reprenant le code il y avait une erreur bidon de pointeur que j'ai ajouté en développant... Donc le problème n'était pas lié à celui de base puisque mon appli cette fois ci ne tournait ni en mode debug, ni en lancant directement. Après correction tout fonctionne dans les deux cas... Mea culpa

Merci quand même à tous pour votre aide