GNOME Bugzilla – Bug 350949
generation of gtk-doc for gnomevfs plugin causes hang if GConf is not running
Last modified: 2006-08-21 14:56:53 UTC
I notice that building the gtk-docs in gst-plugins-base causes a hang, with the following error message: pkgbuild: creating gst-plugins-base-libs-scan pkgbuild: gtk-doc: Running scanner gst-plugins-base-libs-scan After hacking the gtkdoc-scangobj (which builds the gst-plugins-base-libs-scan program) so that it doesn't unlink/delete the gtk-scangobj and running it by hand we also notice the hang. A stacktrace of the process (included at the bottom of this report) shows that the problem is with the ext/gnomevfs plugin. The existance of gst_gnomevfs_get_supported_uris highlights that the problem is with the probe of this plugin. Looking at the gst_gnomevfs_get_supported_uris function where the hang seems to be happening, I see it is doing the following: GnomeVFSURI *uri; gchar *uris[] = { "http://localhost/bla", "file:///bla", "smb://localhost/bla", "ftp://localhost/bla", "sftp://localhost/bla", "nfs://localhost/bla", "ssh://localhost/bla", NULL } , **result; gint n, r = 0; result = g_new (gchar *, 9); for (n = 0; uris[n] != NULL; n++) { uri = gnome_vfs_uri_new (uris[n]); if (uri != NULL) { gchar *protocol = g_strdup (uris[n]); gint n; gnome_vfs_uri_unref (uri); for (n = 0; protocol[n] != '\0'; n++) { if (protocol[n] == ':') { protocol[n] = '\0'; break; } } result[r++] = protocol; } } Looking at the above code, it looks like what the GStreamer VFS plugin is doing is passing in some URI's that are fake (localhost/bla probably does not point to a real file, etc.) and calling gnome_vfs_uri_new to see if GNOME-VFS can manage the URI. Looking at the stack trace, the fact fact that load_module and vfs_module_init is in the stack implies that one of them is causing a gnome-vfs module to get loaded. It seems that the init function for this VFS module is wanting to contact GConf for some reason. In our build environment we normally do not have GConf running so this just hangs. I'm not sure which URI is specifically causing the problem. I notice that commenting out all uri's from the array except for the "file://" one makes the problem go away (probably at the expense of disabling all other URI support from the plugin). Here is the stacktrace of gst-plugins-base-scan at the time of the hang, promised earlier: feb2ada4 read (8, ffbfe2b3, 1) fe5d1b98 try_to_contact_server (1, ffbfe61c, ffffffff, 1628, 22b48, 1400) + 24 fe5d1d1c gconf_get_config_server (0, ffbfe61c, 1628, 22a60, fe5b6635, 1400) + c0 fe5cd8f8 gconf_engine_connect (5cfa0, 1, ffbfe61c, 5cfa0, 26e64, ffbfe5a1) + a0 fe5cdb38 gconf_engine_get_database (5cfa0, 1, ffbfe61c, feb233f4, fecb4430, fecb42c0) + c fe5ce6bc gconf_engine_notify_add (5cfa0, fe447e80, fe5d5230, 35d58, ffbfe61c, 1) + 168 fe5d57c4 gconf_client_add_dir (35d58, fe447e80, 1, ffbfe684, fffe0b70, 0) + ec fe43ad04 proxy_init (14, 1030, fe459f04, 1000, 1f270, 0) + 74 fe43a04c vfs_module_init (5ad68, 0, fe459f04, 10000, 1fecc, 10000) + 18 fe626888 load_module (5cf30, 5ad68, 0, ffbfe824, ffbfe820, 0) + 128 fe626bb0 load_module_in_path_list (3f0a8, 5ad68, 0, ffbfe824, ffbfe820, ffbfe81c) + 58 fe626d18 gnome_vfs_add_module_to_hash_table (0, 177e, bbc, 40c9c, fe667898, fe669b88) + 120 fe626e9c gnome_vfs_transform_get (5ad68, 1b84, 1800, 726dc, fecb2608, 3c) + 68 fe637258 gnome_vfs_uri_new_private (fe677dac, 0, 0, 1, fe677dac, 24) + e0 fe6767a4 gst_gnomevfs_get_supported_uris (5cf00, ffbfe954, fe677dac, 7f4, 116f8, 5cf00) + 68 fe674a3c gst_gnome_vfs_src_uri_get_protocols (0, fe688588, fe687e38, 750, 1342c, 400) + 34 ff1b37e4 gst_element_register (37320, 0, 80, 3f990, 5b480, 48a40) + 290 fe6723b4 plugin_init (37320, fe688488, fe6722f4, fe687e38, 15b40, 0) + c0 ff1d2ee0 gst_plugin_register_func (37320, 0, fe688488, 640c0, ff236d10, ff2100e4) + 294 ff1d362c gst_plugin_load_file (ff23a0d8, 0, 5a4e0, 3f538, 37320, fecb42cc) + 51c ff1d92c8 gst_registry_scan_path_level (38c20, 17000, 7, 0, 484b0, 3f538) + 580 ff1d8ea4 gst_registry_scan_path_level (38c20, 17000, 8, 0, 476d8, 4a600) + 15c ff1d8ea4 gst_registry_scan_path_level (38c20, 17000, 9, 1, 484d0, 40518) + 15c ff1d8ea4 gst_registry_scan_path_level (38c20, 17000, a, 1, 39688, 3fdb8) + 15c ff1d9488 gst_registry_scan_path (38c20, 46768, 17400, ff210bba, ff236d10, ff21f650) + 134 ff198b90 init_post (174, ff239df4, 39638, 0, 3d138, 38c20) + 52c fec475d8 g_option_context_parse (28f08, 0, 0, ffbff2ec, 6d854, fecb2608) + 7d4 ff197fb4 gst_init_check (0, 0, ffbff2ec, 2c00, 9ee30, 0) + d8 ff198004 gst_init (0, 0, feb79040, 9ed2c, ff236d10, ff082000) + 24 00011ef0 main (1, ffbff3bc, ffbff3c4, 27c00, ff080140, ff080180) + 28 000114e0 _start (0, 0, 0, 0, 0, 0) + 108
It would be great if you could narrow the problem down to the protocol that actually causes it. You could do that by creating a stack trace with decent debugging symbols (so that the strings passed to the functions are shown), or by setting the environment variable GST_DEBUG=*:5 and piping the output of stderr to a file and then grepping for _get_supported_uris(). Do you get the same kind of hang with $ gst-launch-0.10 gnomevfssrc location=foo://bar ! fakesink or only when doing the gtk-doc scan thing?
I've narrowed it down to two protocols: http and ftp. The others, file, ssh, nfs, sftp and smb work okay. Let me know if you need the GST_DEBUG and other tests done - I'm in the middle of a biweekly build so only doing the minimum on this today.
From later experiments we have found that this may not be a bug, but a system configuration issue. Our /dev/random and /dev/urandom links were pointing to non existant locations which caused issues. Within the next day or two I will remove the patch from my build (the one that disables http and ftp protocols) and will report back on the findings. I expect that I will be closing the bug at that point.
I removed the patch and the build completes without problem. Sorry for the false alarm. Please close the bus as Not A Bug.
Thanks for investigating this further. Closing.