clair que c'est pas simple.
vu le contexte il doit y avoir pas mal de pression aussi. et ça n'aide pas pour faire les choses calmenent et proprement en général.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
clair que c'est pas simple.
vu le contexte il doit y avoir pas mal de pression aussi
certes.
d'autant plus que la sécurité vient d'éteindre les lumières, signe que je dois arrêter sous peine de me faire virer à coup de pompe dans le c.
donc, clef USB, et codage ce week-end. youpi.
au moins je pourrai coder sur mon pc perso, avec un vrai IDE et des zoulies fenêtre toutes bleues et surtout...un...? un...? un débuggeur!!!!
merci en tout cas de votre soutien, et priez pour ma tête lundi. car elle ne sera pas attachée à grand chose. (et je l'aurai bien mérité)
bon week - end à tous!!
désolé pour les béotiens...
si tu es sur le projet que je pense du coté de Nantes tu comprendra.
J'ai discuté hier avec la personne qui a codé la premiere version de l'ACT FNR sous kis (en 2005), il m'a confié que la gestion des rollbacks pouvait conduire a des incohérences dans certains cas.
maintenant si vous êtes passé a kpsa le code à du prendre de grosses claques et cette remarque n'est peu être plus d'actualités.
si tu croise ceux de vélizy qui était la à l'époque passe leur le bonjour de fred de lyon
hey fred. alors pour te raconter un peu ma vie je bosse à Vélizy (MOE provisioning) et je viens d'apprendre que le projet vient de monter de deux crans pour cause de...? je ne sais pas, je te tiendrai au courant. merci en tout cas de ton soutien, merci à tous d'ailleurs.
En tout cas il n'y a pas de rollback puisque pas de modification SQL (que du select).
gl :c'est en effet un oubli de ma part pour le test d'ouverture, je vais corriger ça, merci
tu as tout à fait raison. je vais arrêter de me focaliser sur cette ligne et essayer d'être plus rigoureux.[EDIT] Une autre petite remarque, ce n'est pas parce que tu as des traces de debug avant une ligne et pas celle après que le problème est forcément sur cette ligne. Le bug apparait ici (et encore avec les bufferisation de stdout, ce n'est même pas certain, il faudrait sortir les traces sur stderr) mais la cause peut se situer bien avant.
c'est probablement ça. Je corrige, je teste et je vous tiens au courant.[Edit bis] Autre problème qui peut potentiellement être la source de l'erreur. En cas d'erreur de lecture (fgets() retourne NULL), tu positionnes bien un flag pour indiquer l'erreur et éventuellement arrêter la boucle de lecture plus tard, mais tu utilise tout de même le buffer de lecture qui ne contient certainement pas des données valides.
De mémoire l'été etais toujours tendu sur ce projet pour cause de mise en prod pour septembre/octobre pour que le système soient près a passer noel....
allé courage
merci. bon. Ca plante toujours. Je ne sais plus quoi faire.
j'ai absolument tout testé, toutes les remarques de gl ont été intégrées à mon code. Je suis tout simplement bloqué. je vais chercher encore, notamment en changeant les fichiers lus. Si quelqu'un a une idée, n'hésitez pas.
Est cce que c'est toujours la même donnée qui fait planter ou pas?
je suis un peu sec sans données pour tester,
peu etre que le fichier d'entrée est verollé....
et tu n'a pas de fonctions type strtok qui te déplace tes pointeurs?
resultat ne fait que 50 en taille, il me semble que les chaines que tu manipule dans ton programme principale sont plus grande non (150)?
ne vas tu pas trop loin dans resultat, dans ce cas ça fait un coredump.....
tu tes NULL pas EOF?
fgets() lit au plus size - 1 caract�res depuis stream et
les place dans le buffer point� par s. La lecture
s'arr�te apr�s EOF ou un retour-chariot. Si un retour-
chariot (newline) est lu, il est plac� dans le buffer. Un
caract�re nul '\0' est plac� � la fin de la ligne.
c'est la valeur de retour de fgets qui est testée... et cette valeur est soit égale au pointeur vers la string modifiée, soir NULL.
j'ai érpouvé cette méthode dans d'autre programmes qui marchent nickel
Je ne sais pas d'où vient l'erreur, et sans tout les éléments (fichier d'exemple, code des fonctions appelées) il est difficile de chercher pour toi.
Ceci étant quelques remarques qui peuvent t'aider à trouver le problème et à avoir un code plus robuste :
- Ne fais pas des fonctions de 300 ou 400 lignes qui font plusieurs choses, découpe ton code en fonctions élémentaires et testes les séparément. Un code aussi long et peu modulaire que celui que tu as est une horreur à lire et à corriger.
- Testes les valeurs de retour des différentes fonctions. Par exemple ici tu utilises joyeusement de la mémoire que tu as allouée sans vérifier si malloc() n'avait pas retourné une erreur.
- Rends les ressources que tu as prises. Ici tu ne libères pas la mémoire allouée et dans certains cas le fichier fichierFNR n'est pas fermé.
- Tu ne testes jamais ce que tu viens de lire (et si fgets() ne lit pas toutes une ligne ? Si il n'y a pas de ; dans les données lues ?). En cas d'erreur de format dans le fichier, il y a une probabilité non nulle que le programme plante.
[EDIT] Une autre petite remarque, ce n'est pas parce que tu as des traces de debug avant une ligne et pas celle après que le problème est forcément sur cette ligne. Le bug apparait ici (et encore avec les bufferisation de stdout, ce n'est même pas certain, il faudrait sortir les traces sur stderr) mais la cause peut se situer bien avant.
[Edit bis] Autre problème qui peut potentiellement être la source de l'erreur. En cas d'erreur de lecture (fgets() retourne NULL), tu positionnes bien un flag pour indiquer l'erreur et éventuellement arrêter la boucle de lecture plus tard, mais tu utilise tout de même le buffer de lecture qui ne contient certainement pas des données valides.
ouille.* Ne fais pas des fonctions de 300 ou 400 lignes qui font plusieurs choses, découpe ton code en fonctions élémentaires et testes les séparément. Un code aussi long et peu modulaire que celui que tu as est une horreur à lire et à corriger.
je ne vais pas te parler de ma méga fonction de fin qui fait 9000 lignes...
cela sera fait* Testes les valeurs de retour des différentes fonctions. Par exemple ici tu utilises joyeusement de la mémoire que tu as allouée sans vérifier si malloc() n'avait pas retourné une erreur.
je m'excuse mais le fichier FNR est fermé à la fin du programme. et en effet je ne fais pas de free pour les string mais cela sera fait aussi* Rends les ressources que tu as prises. Ici tu ne libères pas la mémoire allouée et dans certains cas le fichier fichierFNR n'est pas fermé.
je ne teste pas ce que je viens de lire car le fichier que je lis est généré par un autre sous programme que j'ai codé, qui lui-même test les données et écarte les données vérolées. donc les lignes ne dépasseront jamais 100 caractères, les points virgules seront présents, vu que le fichier est élaboré par mes soins.* Tu ne testes jamais ce que tu viens de lire (et si fgets() ne lit pas toutes une ligne ? Si il n'y a pas de ; dans les données lues ?). En cas d'erreur de format dans le fichier, il y a une probabilité non nulle que le programme plante.
je vais donc de ce pas corriger l'oubli de libération de mémoire et de teste d'allocation, mais, sans vouloir mettre en doute, je doute fort que ça soit ça qui fasse planter...
Non.Envoyé par crashtib
Si l'ouverture de fichierFNR est OK mais qu'il y a une erreur lors de l'ouverture de fichierMPS, tu passe dans le else et le fichier fichierFNR n'est pas fermé.
Sinon j'ai édité mon message pendant que tu répondais. Tu devrais regarder la remarque sur le test des erreurs de lecture.
Répondre avec citation
Partager