GNOME Bugzilla – Bug 136780
libglade xml_new_from_buffer and pixbufs
Last modified: 2004-12-22 21:47:04 UTC
When loading a .glade file using glade_xml_new_from_buffer instead of glade_xml_new I get the following error messages from libglade followed by a core dump: (libglade_test:20188): GLib-CRITICAL **: file gutils.c: line 574 (g_path_get_dirname): assertion `file_name != NULL' failed (libglade_test:20188): GLib-CRITICAL **: file gstrfuncs.c: line 232 (g_strconcat): assertion `string1 != NULL' failed (libglade_test:20188): GdkPixbuf-CRITICAL **: file gdk-pixbuf-io.c: line 729 (gdk_pixbuf_new_from_file): assertion `filename != NULL' failed Segmentation fault (core dumped) the stack trace from the source version 2.0.1 looks like the following:
+ Trace 44986
I decided to look into this bug so i created a sample glade file and test program. this is a major design concern is that the function: glade_xml_relative_file looks like: gchar * glade_xml_relative_file(GladeXML *self, const gchar *filename) { gchar *dirname, *tmp; g_return_val_if_fail(self != NULL, NULL); g_return_val_if_fail(filename != NULL, NULL); g_print( "relative filename: %s\n", filename ); if (g_path_is_absolute(filename)) /* an absolute pathname */ return g_strdup(filename); /* prepend XML file's dir onto filename */ g_print( "self->filename: %s\n", self->filename ); dirname = g_path_get_dirname(self->filename); tmp = g_strconcat(dirname, G_DIR_SEPARATOR_S, filename, NULL); g_free(dirname); return tmp; } This function is very concerning since it is using self->filename, which will not be set if glade_xml_new_from_buffer is used... since it does not expect a filename as a parameter this makes it seem like glade_xml_new_from_buffer is broken. since it cannot be used to load pixmaps the same as glade_xml_new can... To at the very least prevent this bug from causing a seg fault i've created a patch that handles NULL being returned. //////////////////////////////////////////////////////////////////////////////// Index: glade-xml.c =================================================================== RCS file: /cvs/gnome/libglade/glade/glade-xml.c,v retrieving revision 1.107 diff -u -r1.107 glade-xml.c --- glade-xml.c 23 Jan 2004 00:54:35 -0000 1.107 +++ glade-xml.c 10 Mar 2004 17:49:30 -0000 @@ -1548,16 +1548,22 @@ GdkPixbuf *pixbuf; filename = glade_xml_relative_file(xml, string); - pixbuf = gdk_pixbuf_new_from_file(filename, &error); - if (pixbuf) { - g_value_set_object(value, pixbuf); - g_object_unref(G_OBJECT(pixbuf)); - } else { - g_warning("Error loading image: %s", error->message); - g_error_free(error); - ret = FALSE; + if (filename) { + pixbuf = gdk_pixbuf_new_from_file(filename, &error); + if (pixbuf) { + g_value_set_object(value, pixbuf); + g_object_unref(G_OBJECT(pixbuf)); + } else { + g_warning("Error loading image: %s", error->message); + g_error_free(error); + ret = FALSE; + } + g_free(filename); + } + else { + g_warning("Error loading image: %s, Failed to find relative path", string); + ret = FALSE; } - g_free(filename); } else ret = FALSE; break;
Created attachment 25470 [details] [review] patch to keep libglade from segfaulting
Created attachment 25472 [details] test source with glade file
Created attachment 25478 [details] [review] Allows glade_xml_new_from_buffer to work with glade files that don't embed absolute paths and do not include self->filename since glade_xml_new_from_path sets that to NULL
glade_xml_construct there should really be a corresponding glade_xml_construct_from_buffer so that users can set the filename in the gladexml object manually if so desired.
Here's another patch that allows glade_xml_new_from_buffer to fallback to the current working directory instead of only the directory path to the glade file. Really, though this brings up the whole issue of how libglade is handling paths to images and other resources in general. It seems like there needs to be a fix for this that includes modifying the glade format to specify external resource paths. Perhaps another xml file or an embeded resource table... attached is the patch.
Yes, this is a problem. Though if you are using glade_xml_new_from_buffer() it seems odd to load pixmap files. Maybe there should be a callback that the app can use to supply any needed pixmaps or other resources.
>> Yes, this is a problem. Though if you are using >> glade_xml_new_from_buffer() it seems odd to load pixmap files. >> Maybe there should be a callback that the app can use to supply any >> needed pixmaps or other resources. Perhaps, its a misuse on my part; however, I have a an application that is using glade extensively loading different portions of a glade file depending on what screen is being displayed. In this way I can describe a bounding window with multiple internal "frames". I would imagine that calling glade_xml_new_from_buffer should be faster then opening the orginal glade file every time I load a new frame interface; i.e. calling glade_xml_new... So, in an attempt to decrease the start up time of my application I switched over to using glade_xml_new_from_buffer and have a slightly improved startup time. How, might a callback interface work for loading the images? glade_xml_new_from_buffer( const gchar *buffer, gint size, const gchar *root, const gchar *domain, gboolean (*pixbuf_loader)( const gchar*, gpointer ), gpointer user_data ); that's one idea anyway...
*** This bug has been marked as a duplicate of 95315 ***