[Bug 122] Changed - Segmentation fault ?ch?ancier

============================================================================
THIS MESSAGE WAS GENERATED BY THE BUGTRACKER SOFTWARE PLEASE DO NOT REPLY

INSTEAD FOLLOW BUG'S URL BELOW IN ORDER TO DETAIL BUG:
============================================================================
         Bug #: 122 (http://www.grisbi.org/bugtracking/bug.php?op=show&bugid=122)
   Reported By: [email protected]
   Modified By: [email protected]
----------------------------------------------------------------------------
       Summary: Segmentation fault échéancier
           URL: 
       Product: Grisbi stables versions
       Version: 0.4.1
     Component: Grisbi - Main
        Status: Assigned
    Resolution: 
      Severity: Unassigned
    OS/Version: Linux (all)
      Priority: 5 - High
   Assigned To: 
============================================================================
                              COMMENTS

----- Posted by dOm at 6:30 PM on 10-14-2003 -----
J'utilise Grisbi 0.4.1
Voici l'erreur que je reçois lorsque je
double-clique sur certaines opérations de l'échéancier.

Program
received signal SIGSEGV, Segmentation fault.
0x080a33d9 in
edition_echeance () at echeancier_liste.c:1170
1170		  categorie = 
g_slist_find_custom ( liste_struct_categories,


Voici le backtrace
des appels au moment du plantage.

#0  0x080a33d9 in edition_echeance
() at echeancier_liste.c:1170
#1  0x080a2da6 in click_ligne_echeance
(liste=0x82488f0, evenement=0x81d8634, 
    data=0x0) at
echeancier_liste.c:980


Le problÚme se situe dans la fonction
edition_echeance à la ligne 1170 du fichier
"echeancier_liste.c" . Voici l'extrait de code.

categorie =
 g_slist_find_custom ( liste_struct_categories,
		     GINT_TO_POINTER
( echeance_selectionnnee -> categorie ),
		     (GCompareFunc)
recherche_categorie_par_no ) ->data;


Il se trouve que, dans mon
cas, la fonction g_slist_find_custom renvoit un pointeur nul, ce qui
fait que l'acces au membre "->data" plante puisque le
pointeur est nul.
J'ai cherché à comprendre pourquoi la fonction
renvoyait NULL.

En regardant dans le fichier de grisbi (xml), il se
trouve que la catégorie associée est la numéro 15.
Cette catégorie
n'existe plus dans la liste des catégories (toujours dans le fichier
XML).
J'ai certainement demandé la suppression de cette catégorie et
les échéances liées à cette catégorie n'ont pas été réinitialisée à
"sans-catégorie".

Pour corriger mon problÚme, j'ai modifié
le fichier XML pour que les échéances soient à nouveau liées à une
catégorie et une sous catégorie.


Piste pour corriger le problÚme :
- faire des tests au chargement du fichier XML pour vérifier la
cohérence du fichier chargé.
- vérifier si les échéances associées à
une catégorie sont bien réinitialisées à "sans-catégorie"
lorsque cette catégorie est supprimée.
- d'une facon générale, tester
que le résultat renvoyé par une fonction n'est pas NULL.

J'espÚre
vous avoir aidé.

Cordialement 

dOm

----- Posted by Dionysos at 1:04 PM on 11-14-2003 -----
+ Bonjour,
Et merci pour un rapport de bogues si détaillé qui en plus
+ suggÚre des solutions. Cela facilite notre travail.

J'ai donc essayé
+ de chercher plus loin. En dehors du fait que ne pas tester la valeur de
+ retour d'une fonction est une erreur grossiÚre, je pense avoir trouver
+ l'origine du problÚme.
Lorsqu'on souhaite supprimer une catégorie, un
+ test est fait pour savoir si des opérations appartiennent à cette
+ catégorie :
- si c'est le cas, on propose de réaffecter l'opération
+ dans une nouvelle catégorie et on cherche dans l'échéancier s'il y a des
+ opérations planifiées qui appartiennent à la catégorie à supprimer afin
+ de les réaffecter elles aussi.
- si ce n'est pas le cas, on supprime la
+ catégorie SANS VÉRIFIER SI ELLE EST UTILISÉE DANS L'ÉCHÉANCIER.

C'est
+ évidemment un cas de figure trÚs particulier qui vous est probablement
+ arrivé.
Vous avez donc dû créer une opération planifiée dans une
+ catégorie particuliÚre avec une date qui n'a pas permis une création
+ effective de l'opération, puis, plus tard, supprimer la catégorie qui
+ vous ne convenez pas.
Nous allons essayer de corriger cela assez
+ rapidement. En tout cas, merci encore pour votre rapport de bogue qui
+ m'a permis de mieux cerner le problÚme originel.
Si tout le monde en
+ faisait autant, les bogues se corrigeraient plus rapidement :-)
+ Cordialement,
Alain





-- 
Pour vous desabonner envoyez un mail a [email protected]