g_file_resolve_relative_path() fails to resolve some relative paths
@stanislav-brabec
Submitted by Stanislav Brabec Link to original bug (#627491)
Description
Created attachment 168403 gfile-resolve.c
Suppose to have two files:
/usr/lib64/browser-plugins/opensc-signer.so -> ../opensc-signer.so links to /usr/lib64/opensc-signer.so, which is a file
/usr/lib64/browser-plugins/npwrapper.so -> ../../lib/nspluginwrapper/x86_64/linux/npwrapper.so links to /usr/lib/nspluginwrapper/x86_64/linux/npwrapper.so, which is a file
Running attached trivial testcase, I see:
resolving /usr/lib64/browser-plugins/opensc-signer.so link=../opensc-signer.so resolved=/usr/lib64/browser-plugins/opensc-signer.so resolving /usr/lib64/browser-plugins/npwrapper.so link=../../lib/nspluginwrapper/x86_64/linux/npwrapper.so resolved=/usr/lib64/lib/nspluginwrapper/x86_64/linux/npwrapper.so
In the first case, the relative path is apparently resolved incorrectly.
Marking bug as Critical. This problem causes freeze of epiphany web browser whenever opensc package is installed (smart card signer). The hang appears in webkit-1.2.0/WebCore/plugins/gtk/PluginPackageGtk.cpp PluginPackage::load() (while (g_file_test(finalPath.get(), G_FILE_TEST_IS_SYMLINK))...)
Off-topic note: The need of g_type_init () before being able to use any GFile function is completely missing in the documentation and causes crash:
#0 0x0000000000000000 in ?? ()
#1 0x00007ffff7b6e4a7 in _g_io_modules_ensure_extension_points_registered () at giomodule.c:507
#2 0x00007ffff7b6e62d in _g_io_modules_ensure_loaded () at giomodule.c:546
#3 0x00007ffff7b86e38 in get_default_vfs (arg=<value optimized out>) at gvfs.c:187
#4 0x00007ffff704ea6a in IA__g_once_impl (once=0x7ffff7ddc950, func=0x7ffff7b86e20 <get_default_vfs>, arg=0x0) at gthread.c:1045
#5 0x00007ffff7b5c38e in IA__g_file_new_for_path (path=0x400b70 "/usr/lib64/browser-plugins/opensc-signer.so") at gfile.c:5897
#6 0x00000000004009a8 in main () at gfile-test.c:13
Attachment 168403, "gfile-resolve.c":
gfile-resolve.c