From owner-freebsd-gnome@FreeBSD.ORG Thu May 4 16:55:42 2006 Return-Path: X-Original-To: gnome@freebsd.org 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 51F3516A402 for ; Thu, 4 May 2006 16:55:42 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from creme-brulee.marcuscom.com (creme-brulee.marcuscom.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id C78D143D45 for ; Thu, 4 May 2006 16:55:41 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from custard.marcuscom.com (custard.marcuscom.com [192.168.1.1]) by creme-brulee.marcuscom.com (8.13.6/8.13.6) with ESMTP id k44GtBak081957; Thu, 4 May 2006 12:55:13 -0400 (EDT) (envelope-from marcus@marcuscom.com) Date: Thu, 4 May 2006 12:55:06 -0400 (EDT) From: Joe Marcus Clarke To: Vladimir Grebenschikov In-Reply-To: <1146738978.1476.39.camel@localhost> Message-ID: <20060504125404.X81868@creme-brulee.marcuscom.com> References: <20060503220122.509DF45053@ptavv.es.net> <1146725374.1476.31.camel@localhost> <1146738978.1476.39.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: gnome@freebsd.org Subject: Re: Very slow screensaver with 2.14 X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.5 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, 04 May 2006 16:55:42 -0000 On Thu, 4 May 2006, Vladimir Grebenschikov wrote: > ? ??, 04/05/2006 ? 10:49 +0400, Vladimir Grebenschikov ?????: >> ? ??, 03/05/2006 ? 15:01 -0700, Kevin Oberman ?????: >>> The new gnome-screensaver in 2.14 is unbelievably slow. On my 1GHz >>> system it takes over 20 seconds to bring up the password window. I can't >>> imagine what it is doing all of this time. The screen un-blanks and the >>> cursor appears almost instantly, but it just sits there at that >>> point. On my 2GHz system, it 'only' takes about 6 seconds and my >>> Athlon-64x2 4400+ even takes about 4 seconds. >>> >>> Anyone have any idea what is going on? Waiting 22 seconds is simply >>> painful! >> >> I have same problem, It incredible slow when there is some other >> activity (buildworld in background for example). >> >> Looks like it requires too much pages to show input window, and all >> theses pages thrown out while other activity and then loaded too slow. > > I have idea why it happens, looks like gnome-screensaver execs > /usr/X11R6/libexec/gnome-screensaver-dialog on activation event > > And binary starts to map whole big set of libraries: > > % ldd /usr/X11R6/libexec/gnome-screensaver-dialog > /usr/X11R6/libexec/gnome-screensaver-dialog: > libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x28095000) > libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x2809d000) > libXss.so.1 => /usr/X11R6/lib/libXss.so.1 (0x280b3000) > libXxf86vm.so.1 => /usr/X11R6/lib/libXxf86vm.so.1 (0x280b6000) > libXxf86misc.so.1 => /usr/X11R6/lib/libXxf86misc.so.1 (0x280bb000) > libgtk-x11-2.0.so.0 => /usr/X11R6/lib/libgtk-x11-2.0.so.0 (0x280be000) > libgdk-x11-2.0.so.0 => /usr/X11R6/lib/libgdk-x11-2.0.so.0 (0x28369000) > libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x283e2000) > libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x283e6000) > libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 (0x283ee000) > libatk-1.0.so.0 => /usr/local/lib/libatk-1.0.so.0 (0x283f1000) > libgdk_pixbuf-2.0.so.0 => /usr/X11R6/lib/libgdk_pixbuf-2.0.so.0 (0x28409000) > libpangocairo-1.0.so.0 => /usr/X11R6/lib/libpangocairo-1.0.so.0 (0x2841d000) > libXcursor.so.1 => /usr/X11R6/lib/libXcursor.so.1 (0x28425000) > libXfixes.so.3 => /usr/X11R6/lib/libXfixes.so.3 (0x2842e000) > libcairo.so.2 => /usr/local/lib/libcairo.so.2 (0x28433000) > libpng.so.5 => /usr/local/lib/libpng.so.5 (0x2847b000) > libpangoft2-1.0.so.0 => /usr/X11R6/lib/libpangoft2-1.0.so.0 (0x2849e000) > libfontconfig.so.1 => /usr/X11R6/lib/libfontconfig.so.1 (0x284c3000) > libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x284ef000) > libfreetype.so.9 => /usr/local/lib/libfreetype.so.9 (0x2850d000) > libpango-1.0.so.0 => /usr/X11R6/lib/libpango-1.0.so.0 (0x28572000) > libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x285a9000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x285b1000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x28672000) > libgnomevfs-2.so.0 => /usr/X11R6/lib/libgnomevfs-2.so.0 (0x2867f000) > libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x286d9000) > libz.so.3 => /lib/libz.so.3 (0x287e1000) > libssl.so.4 => /usr/local/lib/libssl.so.4 (0x287f2000) > libcrypto.so.4 => /usr/local/lib/libcrypto.so.4 (0x2882a000) > libavahi-glib.so.1 => /usr/local/lib/libavahi-glib.so.1 (0x2893c000) > libavahi-client.so.3 => /usr/local/lib/libavahi-client.so.3 (0x2893f000) > libdbus-1.so.2 => /usr/local/lib/libdbus-1.so.2 (0x2894d000) > libavahi-common.so.3 => /usr/local/lib/libavahi-common.so.3 (0x2897e000) > libutil.so.5 => /lib/libutil.so.5 (0x28988000) > libbonobo-2.so.0 => /usr/local/lib/libbonobo-2.so.0 (0x28994000) > libgconf-2.so.4 => /usr/X11R6/lib/libgconf-2.so.4 (0x289e4000) > libbonobo-activation.so.4 => /usr/local/lib/libbonobo-activation.so.4 (0x28a12000) > libORBitCosNaming-2.so.0 => /usr/local/lib/libORBitCosNaming-2.so.0 (0x28a25000) > libORBit-2.so.0 => /usr/local/lib/libORBit-2.so.0 (0x28a29000) > libpopt.so.0 => /usr/local/lib/libpopt.so.0 (0x28a7f000) > libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x28a86000) > libm.so.4 => /lib/libm.so.4 (0x28abb000) > libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x28ad0000) > libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x28ad3000) > libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x28ad7000) > libintl.so.6 => /usr/local/lib/libintl.so.6 (0x28b56000) > libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28b5f000) > libcrypt.so.3 => /lib/libcrypt.so.3 (0x28c4c000) > libpthread.so.2 => /lib/libpthread.so.2 (0x28c64000) > libc.so.6 => /lib/libc.so.6 (0x28c89000) > % > > Very probably, that part of them already thrown out from memory, and should be reread from disk. > >> I guess gdb will not help here, but I will try anyway. > > No luck with gdb: > > % ps alx | fgrep saver > 207 1361 1 0 96 0 17772 9296 select Ss ?? 0:08.26 gnome-screensaver > 207 60171 1361 183 118 0 43180 15372 - R ?? 0:11.71 /usr/X11R6/libexec/gnome-screensaver-dialog > 207 60187 60177 4 96 0 1588 956 - R+ v0 0:00.00 fgrep saver > % gdb gnome-screen-saver 1361 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"...gnome-screen-saver: No such file or directory. > > Attaching to process 1361 > /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c:1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) y > > /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c:1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Create a core file of GDB? (y or n) n > % uname -a > FreeBSD vbook.fbsd.ru 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Mon Apr 17 13:52:39 MSD 2006 root@vbook.fbsd.ru:/usr/obj/usr/src/sys/VBOOK i386 > % > >> Contrary, I xscreensaver popup password window relatively quick even >> when there is heavy activity on machine. Thanks for the explanation. This kind of thing will not be unique to FreeBSD. I recommend you open a bug in GNOME Bugzilla if one does not already exist. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc