Segfault ou Gtk-Critical (Au hasard)

Version imprimable

Bonjour, je rencontre un soucis dans le développement de mon code en C/GTK+
Quelques jours que je suis dessus sans trouver la solution.
Je poste dans le forum Gtk+ car quelques indices me laissent à penser que cela vient de ça même si je n'en suis pas forcément sur.
En fait mon code va, soit planter avec une segfault. Dans ce cas la, le backtrace de gdb ou valgrind ne m'est vraiment pas d'une très grande utilité car il ne m'indique raucun endroit de mon code :

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
La sortie de valgrind avec : --track-origins=yes
==6968== Invalid read of size 4
==6968==    at 0x5119151: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1400.5)
==6968==    by 0x513BCAC: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1400.5)
==6968==    by 0x6AF3244: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==6968==    by 0x6B04F6B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==6968==    by 0x6B0D777: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==6968==    by 0x6B0D9DE: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==6968==    by 0x4FCD20B: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1400.5)
==6968==    by 0xE424DBF: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.2)
==6968==    by 0xE424827: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.2)
==6968==    by 0x6AF3EBB: g_cclosure_marshal_generic_va (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==6968==    by 0x6AF3473: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==6968==    by 0x6B0D086: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==6968==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==6968== 
==6968== 
==6968== Process terminating with default action of signal 11 (SIGSEGV)
==6968==  Access not within mapped region at address 0x0
==6968==    at 0x5119151: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1400.5)
==6968==    by 0x513BCAC: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1400.5)
==6968==    by 0x6AF3244: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==6968==    by 0x6B04F6B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==6968==    by 0x6B0D777: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==6968==    by 0x6B0D9DE: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==6968==    by 0x4FCD20B: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1400.5)
==6968==    by 0xE424DBF: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.2)
==6968==    by 0xE424827: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.6.0.2)
==6968==    by 0x6AF3EBB: g_cclosure_marshal_generic_va (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==6968==    by 0x6AF3473: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==6968==    by 0x6B0D086: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)

Lorsqu'il ne segfault pas, j'ai droit à ça :

Code:

1
2
3
4
5
6
7
8
9
10
11
(siril:11890): Gtk-CRITICAL **: _gtk_rbtree_reorder: assertion 'tree->root->count == length' failed
 
(siril:11890): Gtk-CRITICAL **: _gtk_rbtree_reorder: assertion 'tree->root->count == length' failed
 
(siril:11890): Gtk-CRITICAL **: _gtk_rbtree_reorder: assertion 'tree->root->count == length' failed
 
(siril:11890): Gtk-CRITICAL **: _gtk_rbtree_reorder: assertion 'tree->root->count == length' failed
 
(siril:11890): Gtk-CRITICAL **: _gtk_rbtree_reorder: assertion 'tree->root->count == length' failed
 
(siril:11890): Gtk-CRITICAL **: gtk_tree_view_unref_tree_helper: assertion 'node != NULL' failed

Effectivement j'utilise un gtk_tree_vew qui liste des fichiers images. En le parcourant je créé de nouveau fichier et le plantage/warning apparrait lorsque j'écrase des fichiers existant portant le même nom.
J'ai tenté un break g_log dans gdb mais cela me retourne le même genre de backtrace que dans valgrind.
Bref, je suis un peu perdu et je sais pas du tout ou regarder.

Pour lister les fichiers, j'utilise une GSList de la sorte :

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
	static GtkTreeView *tree_convert = NULL;
	GtkTreeModel *model = NULL;
	GtkTreeIter iter;
	gboolean valid;
	gchar *file_data;
	GList *list = NULL;
	int count = 0;
 
	if (tree_convert == NULL)
		tree_convert = GTK_TREE_VIEW(gtk_builder_get_object(builder, "treeview_convert"));
 
        [...]
 
	model = gtk_tree_view_get_model(tree_convert);
	valid = gtk_tree_model_get_iter_first(model, &iter);
	if (valid == FALSE) return;	//The tree is empty
 
	while (valid) {
		gtk_tree_model_get (model, &iter, 0, &file_data, -1);	// 0 for FILECOLUMN
		list = g_list_append (list, file_data);
		valid = gtk_tree_model_iter_next (model, &iter);
		count ++;
	}
        [...]

Si quelqu'un avait une idée du pourquoi et du comment, ça serait génial.

Bonne soirée,
Cordialement

07/01/2015, 18h51
gerald3d

Bonsoir.

file_data est de quel type ?
07/01/2015, 18h57
lock42

Ah oups j'ai oublié de le mettre dans le post, il est de type gchar.

Code:

gchar *file_data;
07/01/2015, 19h12
gerald3d

Lorsque tu insères ce pointeur dans la GSList es-tu sûr par la suite que chaque pointeur pointe toujours sur un espace réservé ? Pour ma part je pense qu'il faudrait faire une copie de chaque file_data avec un malloc(); et d'insérer celle-ci dans la liste.

Bien entendu cela implique une fonction qui libère tous ces malloc(); lorsque tu désires détruire la liste.
07/01/2015, 19h30
lock42

Hum, je suis désolé mais je ne suis pas sûr de comprendre.

Tu voudrais qu'avant le

Code:

gtk_tree_model_get

j'alloue de la mémoire a file_data ? en faisant un tableau de file_data ? (dans ce cas je perds l'avantage a faire une liste si je dois prévoir un tableau de char*)
Car sinon, effectivement "file_data" est écrasé a chaque boucle, et je pensais que la valeur était copié lors du g_list_append.

Si j'écris ça :

Code:

1
2
3
4
5
6
7
	while (valid) {
		gtk_tree_model_get (model, &iter, 0, &file_data, -1);	// 0 for FILECOLUMN
		char *str = strdup(file_data);
		list = g_list_append (list, str);
		valid = gtk_tree_model_iter_next (model, &iter);
		count ++;
	}

sans me préoccuper des free dans un premier temps et j'ai toujours ma segfault.

07/01/2015, 20h36
gerald3d

Au temps pour moi alors :(

J'avoue ne pas trop savoir alors d'où vient ton problème. :oops:
07/01/2015, 20h52
lock42

Merci d'être passé par là et d'avoir essayé.
Si quelqu'un d'autres passant par ici est à même de m'aider, ca sera avec plaisir !!!!
07/01/2015, 20h55
gerald3d

Le problème vient peut être alors de la partie du code qui lit ta liste pour créer/écraser les fichiers sur disque. Serait-il possible de voir cette partie du code ?

Pas de soucis, c'est un projet open-source :)
En simplifiant pour la lecture, je fais ca comme ceci :

Code:

1
2
3
4
5
6
7
8
9
10
11
	args->list = g_list_first (args->list);
	while(args->list) {
		sourcefilename = (char *)args->list->data;
		snprintf(destfilename, 255, "%s%03d.%s", destroot, ++i, destsuf);
		strncpy(sourcesuf, get_filename_ext(sourcefilename), SUFFIX_MAX_LEN);
		[...]
		tofits(sourcefilename, destfilename);    // ici ca enregistre
		[...]
		set_progress_bar_data(NULL, (double)i/((double)args->total));
		args->list = g_list_next(args->list);
	}

07/01/2015, 21h17
gerald3d

Sans préjugé le problème pourrait provenir des fonctions snprintf(); et strncpy();. La Glib met à ta dispositions des fonctions de traitement plus avancées au cas où...

Si tu commentes ces lignes obtiens-tu toujours les segdefault ?
07/01/2015, 21h30
lock42

Je peux pas les commenter sans devoir commenter un peu tout.
A quelle fonction penses tu ? Je pourrais essayer de les utiliser :)
07/01/2015, 21h38
gerald3d

Pour strncpy tu as g_strndup();

Pour snprintf(); il y a g_snprintf();

Code:

1
2
g_snprintf(destfilename, 255, "%s%03d.%s", destroot, ++i, destsuf);
sourcesuf = g_strndup (get_filename_ext(sourcefilename), SUFFIX_MAX_LEN);

Ne résout malheureusement pas le problème ;'(

07/01/2015, 21h48
gerald3d

Bon on poursuit alors ;). Si tu commentes la fonction tofits(); tu as toujours le problème ?
07/01/2015, 21h52
lock42

Non.
En fait le problème dans tofits (fonction de conversion) j'ai plusieurs appels qui vont remonter jusqu'a une fonction appelée savefit.
Dans cette dernière il va y'avoir un unlink(filename). Si je commande ce unlink, ca ne plantera pas (mais du coup ca n'écrasera pas, et n'enregistrera pas le nouveau fichier).

Cependant. Si je fais une conversion de nouveaux fichiers (donc sans écrasement) ca ne plante pas. MAIS si pendant que le soft est ouvert et juste après la création des fichiers, si je supprime les-dits fichiers manuellement, alors ca fera crasher le soft ....
07/01/2015, 22h07
gerald3d

Citation:

Envoyé par lock42

...
Cependant. Si je fais une conversion de nouveaux fichiers (donc sans écrasement) ca ne plante pas. MAIS si pendant que le soft est ouvert et juste après la création des fichiers, si je supprime les-dits fichiers manuellement, alors ca fera crasher le soft ....

Ici le problème vient sûrement du fait que tu gardes en mémoire (dans ta liste) des noms de fichier qui n'existent plus. Peut être vaudrait-il ajouter une vérification avant toute manipulation de ces dits fichiers.
07/01/2015, 22h09
lock42

La liste contient les fichier sources. Or c'est si je supprime les fichiers destinations ...
Car les fichiers sources sont gardés quoiqu'il arrive ....
07/01/2015, 22h24
gerald3d

J'en perds mon latin :aie::fou:
07/01/2015, 22h44
lock42

Moi aussi ....
J'en deviens fou :(

C'est frustrant de voir un invalid read size dans valgrind et de pas pouvoir le localiser ......
07/01/2015, 23h05
lock42

Que signifient les Gtk-Critical déja ?
08/01/2015, 08h57
lock42

Bon ben mon collègue sur le projet a trouvé d'ou vient le probleme :
C'est un bug du GtkFileChooser. Pour fixer le problème il faut détruire le GtkFileChooserDialog après utilisation. Le problème du coup c'est que ca rend pas hyper compatible avec l'utilisation du glade.
Peux t on ne réinstancier le GtkFileChooserDialog depuis le glade, ou bien dois-je le définir dans le code ?
08/01/2015, 10h51
gerald3d

Content pour toi que tu ais pu mettre le doigt sur le problème.

Pour l'utilisation de Glade, une solution serait d'avoir un fichier Glade que pour le GtkFileChooserDialog. Tu peux ainsi le charger à chaque appel et ainsi le détruire par la suite. Sinon la construction inline est aussi intéressante si tu ne modifies pas trop son contenu.
08/01/2015, 12h09
lock42

Cela ne m'a pas pris plus de 5min a modifier; donc ça va.
Par contre il faudrait essayer de trouver le bug et le remonter à GTK.

En tout cas, merci pour ton aide.