Segfault ou Gtk-Critical (Au hasard)

**lock42** · 07/01/2015, 18h37

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 :

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
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 :

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

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 :

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
	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

**gerald3d** · 07/01/2015, 19h51

Bonsoir.

file_data est de quel type ?

**lock42** · 07/01/2015, 19h57

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

Code :

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

gchar *file_data;

**gerald3d** · 07/01/2015, 20h12

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.

**lock42** · 07/01/2015, 20h30

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

Tu voudrais qu'avant le

Code :

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

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.

**lock42** · 07/01/2015, 20h41

Si j'écris ça :

Code :

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

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.

**gerald3d** · 07/01/2015, 21h36

Au temps pour moi alors

J'avoue ne pas trop savoir alors d'où vient ton problème.

**lock42** · 07/01/2015, 21h52

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 !!!!

**gerald3d** · 07/01/2015, 21h55

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 ?

**lock42** · 07/01/2015, 22h01

Pas de soucis, c'est un projet open-source

En simplifiant pour la lecture, je fais ca comme ceci :

Code :

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

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);
	}

**gerald3d** · 07/01/2015, 22h17

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 ?

**lock42** · 07/01/2015, 22h30

Je peux pas les commenter sans devoir commenter un peu tout.
A quelle fonction penses tu ? Je pourrais essayer de les utiliser

**gerald3d** · 07/01/2015, 22h38

Pour strncpy tu as g_strndup();

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

**lock42** · 07/01/2015, 22h45

Code :

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

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 ;'(

**gerald3d** · 07/01/2015, 22h48

Bon on poursuit alors

. Si tu commentes la fonction tofits(); tu as toujours le problème ?

**lock42** · 07/01/2015, 22h52

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 ....

**gerald3d** · 07/01/2015, 23h07

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.

**lock42** · 07/01/2015, 23h09

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 ....