From owner-freebsd-gnome@FreeBSD.ORG Wed Apr 21 18:03:18 2004 Return-Path: Delivered-To: freebsd-gnome@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51DE916A4CE for ; Wed, 21 Apr 2004 18:03:18 -0700 (PDT) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id C794B43D49 for ; Wed, 21 Apr 2004 18:03:17 -0700 (PDT) (envelope-from marcus@FreeBSD.org) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) i3M12A7v006538 for ; Wed, 21 Apr 2004 21:02:10 -0400 (EDT) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: FreeBSD GNOME Users Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-bgx1jfzkA0JOEs+pvgoM" Organization: FreeBSD, Inc. Message-Id: <1082595788.34974.23.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 21 Apr 2004 21:03:08 -0400 Subject: Problems with the new file selector and non-threaded applications X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 01:03:18 -0000 --=-bgx1jfzkA0JOEs+pvgoM Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Background: ----------- Gtk+ 2.4 comes with a new file selector UI that can be extended with pluggable file system modules. Libgnomeui includes such a modules that makes use of gnome-vfs. This module is automatically used by gtk+ applications if run under the GNOME desktop or when gnome-settings-daemon is running (if libgnomeui is installed, that is). Problem: -------- If a non-threaded gtk+ application calls the new file selection UI, and the gnome-vfs file system module is loaded, that application will immediately crash with a segmentation fault. The stack trace looks something like: #1 0x28b474b5 in _spinlock_debug () from /usr/lib/libc_r.so.5 No symbol table info available. #2 0x28b4c873 in _mutex_cv_lock () from /usr/lib/libc_r.so.5 No symbol table info available. #3 0x28b4c738 in _mutex_cv_unlock () from /usr/lib/libc_r.so.5 No symbol table info available. #4 0x28b50e50 in _pthread_cond_wait () from /usr/lib/libc_r.so.5 No symbol table info available. #5 0x28b50fa0 in pthread_cond_wait () from /usr/lib/libc_r.so.5 No symbol table info available. #6 0x288af4e3 in pthread_cond_wait () from /lib/libc.so.5 No symbol table info available. #7 0x28a00262 in giop_recv_buffer_get (ent=3D0xbfbfd9d0) at giop-recv-buffer.c:707 tdata =3D (GIOPThread *) 0x8090320 ... Non-threaded applications cannot link to or dlopen() threaded libraries in FreeBSD 5.X. The reason is (according to eischen on hackers@): "I think most of the problem is that our synchronization types are private to each threads library." This should be fixed in FreeBSD 6.X. FreeBSD 4.X is not affected because it uses -pthread to link threaded objects, and -pthread will not explicitly link libc_r to shared objects. Solution: --------- We don't have a good one at this point. Here's what I see as possible solutions: 1. Set GNOME's PTHREAD_LIBS to -pthread for all versions of FreeBSD.=20 _Pros:_ This should fix the problem as it will emulate what 4.X does, and ORBit will do the right thing in the non-threaded case. _Cons:_ I haven't tested this on 5.2.1, but it will work on -CURRENT. We will have to relink all applications that depend on gtk20 to make this 100% effective. 2. Explicitly link all gtk+ applications that use the new file selection UI to PTHREAD_LIBS by adding PTHREAD_LIBS to the gtk+-2.0.pc file.=20 _Pros:_ This will solve the problem for all dynamically loaded gtk+ modules. _Cons:_ We will be linking otherwise non-threaded apps to PTHREAD_LIBS. This will not fix other g_modules. 3. Teach gtk+ not to load a threaded file system modules into a non-threaded application. _Pros:_ This will fix the problem at hand with the file selector UI. This is a very surgical fix in that only one port needs to be touched. _Cons:_ We will be introducing a gross hack that will need to be forward-ported to new versions of gtk+. This only helps with the file system modules. This means that non-threaded gtk+ applications will not be able to access VFS objects through the file selection UI (not that they could before with earlier versions of gtk+ though). 4. Teach glib not to load threaded modules into non-threaded applications. _Pros:_ This will fix the problem for all g_modules.=20 _Cons:_ This introduces a gross hack that will have to be forward ported to new versions of glib. This means that non-threaded applications will not be able to take advantage of threaded modules. 5. Don't configure the gnome-vfs file system for all gtk+ applications.=20 Instead, only do it for apps that link to libgnomeui. _Pros:_ This should fix the problem for the file selector (though I haven't looked into this solution much). This only affects two ports, and will not require much nasty hacking. _Cons:_ We will still need to forward-port our hack. This means pure gtk+ apps will not be able to access VFS objects through the file selector. 6. ??? If you have a better idea, I'm all ears. I would love to ultimately fix this problem with the least amount of nasty hacking, while still giving users the maximum amount of functionality. Thanks for listening. Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-bgx1jfzkA0JOEs+pvgoM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAhxnLb2iPiv4Uz4cRAgpuAJsHNAd+lMFfBflY/z/23lAn3E9XfgCeNllH XSluRxSz8ZEVZWUD/4lhYPQ= =DfZb -----END PGP SIGNATURE----- --=-bgx1jfzkA0JOEs+pvgoM--