Created attachment 272777 [details] emerge --info While trying to track down bug 365479 I came across the following weirdness, which may be related (or not). Please try to reproduce and report here... If libproxy is built with USE="webkit -kde", the query program /usr/bin/proxy segfaults somewhere in NVidia OpenGL (!). All other combinations of these useflags work fine. Details below. *** libproxy -kde +webkit Core was generated by `proxy http://www.google.com/'. Program terminated with signal 11, Segmentation fault. #0 __libc_free (mem=0x1) at malloc.c:3710 3710 malloc.c: Datei oder Verzeichnis nicht gefunden. in malloc.c (gdb) bt #0 __libc_free (mem=0x1) at malloc.c:3710 #1 0x00007ff33bdbf335 in _dlerror_run (operate=0x7ff33bdbef10 <dlopen_doit>, args=0x7fff5dfd3d70) at dlerror.c:160 #2 0x00007ff33bdbeef1 in __dlopen (file=<value optimized out>, mode=<value optimized out>) at dlopen.c:88 #3 0x00007ff3312b1ccd in ?? () from //usr/lib64/opengl/nvidia/lib/libGL.so.1 #4 0x00007ff3312b94a7 in ?? () from //usr/lib64/opengl/nvidia/lib/libGL.so.1 #5 0x00007ff33ce928c9 in call_init (l=0x1606550, argc=2, argv=0x7fff5dfed718, env=0x7fff5dfed730) at dl-init.c:70 #6 0x00007ff33ce929fe in _dl_init (main_map=0x164bbf0, argc=2, argv=0x7fff5dfed718, env=0x7fff5dfed730) at dl-init.c:134 #7 0x00007ff33ce96da5 in dl_open_worker (a=<value optimized out>) at dl-open.c:463 #8 0x00007ff33ce92566 in _dl_catch_error (objname=<value optimized out>, errstring=<value optimized out>, mallocedp=<value optimized out>, operate=<value optimized out>, args=<value optimized out>) at dl-error.c:178 #9 0x00007ff33ce9658a in _dl_open (file=0x1650448 "/usr/lib64/libproxy/0.4.6/modules/pacrunner_webkit.so", mode=-2147483647, caller_dlopen=0x7ff33c70b850, nsid=-2, argc=2, argv=0xa, env=0x7fff5dfed730) at dl-open.c:554 #10 0x00007ff33bdbef76 in dlopen_doit (a=<value optimized out>) at dlopen.c:67 #11 0x00007ff33ce92566 in _dl_catch_error (objname=<value optimized out>, errstring=<value optimized out>, mallocedp=<value optimized out>, operate=<value optimized out>, args=<value optimized out>) at dl-error.c:178 #12 0x00007ff33bdbf2fc in _dlerror_run (operate=0x7ff33bdbef10 <dlopen_doit>, args=0x7fff5dfd4280) at dlerror.c:164 #13 0x00007ff33bdbeef1 in __dlopen (file=<value optimized out>, mode=<value optimized out>) at dlopen.c:88 #14 0x00007ff33c70b850 in libmodman::module_manager::load_file (this=0x1605148, filename=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece or DW_OP_bit_piece. ) at /var/tmp/portage/net-libs/libproxy-0.4.6-r2/work/libproxy-0.4.6/libmodman/module_manager.cpp:250 #15 0x00007ff33c70bdec in libmodman::module_manager::load_dir (this=<value optimized out>, dirname=<value optimized out>, symbreq=<value optimized out>) at /var/tmp/portage/net-libs/libproxy-0.4.6-r2/work/libproxy-0.4.6/libmodman/module_manager.cpp:327 #16 0x00007ff33cc73fcc in libproxy::proxy_factory::proxy_factory (this=0x1605120) at /var/tmp/portage/net-libs/libproxy-0.4.6-r2/work/libproxy-0.4.6/libproxy/proxy.cpp:159 #17 0x00007ff33cc7416a in pxProxyFactory_ () at /var/tmp/portage/net-libs/libproxy-0.4.6-r2/work/libproxy-0.4.6/libproxy/proxy.cpp:406 #18 px_proxy_factory_new () at /var/tmp/portage/net-libs/libproxy-0.4.6-r2/work/libproxy-0.4.6/libproxy/proxy.cpp:411 #19 0x0000000000400c48 in main (argc=1, argv=0x7ff33bdbf240) at /var/tmp/portage/net-libs/libproxy-0.4.6-r2/work/libproxy-0.4.6/utils/proxy.c:67 *** libproxy +kde +webkit works *** libproxy +kde -webkit works *** libproxy -kde -webkit works
Uhm. This looks "fun". libproxy calls dlopen(); dlopen() causes the libraries to initialize when opened (as intended), but in the init, libGL.so.1 is calling dlopen() further ... since dlopen() is non-reentrant this is getting out of control.
This problem will get alleviated when webkit-gtk-1.6 enters tree since JSCore will been split out[1], and won't link to any problematic libraries. In the meantime, I recommend that we temporarily disable USE=webkit on libproxy. This has already been done in the gnome overlay because of gtk2/gtk3 problems. Additionally, we should note that xulrunner will soon become monolithic, and libmozjs.so will be provided by spidermonkey (alongwith a new pkgconfig file[2]). Hence, libproxy will need to be patched for that in the future, otherwise it will begin linking with libxul.so and cause the same problems again. 1. https://bugs.webkit.org/show_bug.cgi?id=19428 2. https://bugzilla.mozilla.org/show_bug.cgi?id=628723
+*libproxy-0.4.6-r3 (05 Jun 2011) + + 05 Jun 2011; Pacho Ramos <pacho@gentoo.org> +libproxy-0.4.6-r3.ebuild, + +files/libproxy-0.4.6-backports.patch, + +files/libproxy-0.4.6-flags-mixing.patch: + Revision bump disabling webkit support as it causes problems like bug #366791 + (we will be able to recover this with webkit-1.6), do the same for xulrunner + support because of important problems like bug #360893 giving unresolved + symbols due problems to use proper mozjs. Thanks a lot to Nirbheek for his + assistance with this. Also include and old upstream patch to stop mixing + CFLAGS and CXXFLAGS (bug #338125 by Justin Lecher) and an opensuse patch + including some more fixes from upstream. +
Created attachment 309461 [details, diff] ebuild patch to libproxy-0.4.7 to enable webkit Now, with net-libs/webkit-gtk-1.8.0:2 or net-libs/webkit-gtk-1.8.0:3 this no longer crashes with USE="-kde webkit", even with nvidia drivers. Seems to be the only possibility to give libproxy access to a working pacrunner right now, like in this example with the "proxy" test utility, but of course the benefit of it would show in some real CLI utilities using libproxy: libproxy-0.4.7 # _PX_DEBUG=1 ftp_proxy=pac+http://server/path/to/proxy.pac proxy ftp://ftp.mozilla.org/pub/ls-lR.gz Using config: 23envvar_config_extension Using ignore: Config is: pac+http://server/path/to/proxy.pac PAC received! Using pacrunner: 26webkit_pacrunner_extension Pacrunner returned: PROXY ftp-proxy.t-online.de http://ftp-proxy.t-online.de
