Tuesday Jul 15, 2008

Thanks to the organizers of GUADEC 2008!

Istanbul Sunset

Many thanks to the organizers, volunteers and Gnomers who helped make GUADEC 2008 possible! There were a few glitches (please open up SSL and VPN ports next time!), but overall it was a success. I also appreciate being able to present my talk on measuring the GNOME footprint. If I'd anticipated the interest, I would have gone into more detail regarding the extensive use of dtrace in this study, but John Rice covered that well in his talk. I'll try to post the details here as soon as possible. I also appreciate the fact that my friend Andrei, a Google Summer of Code student, is eager to use some of my techniques in his memory profile study. It was great to see my friends again and I look forward to seeing them again at a future GUADEC!

The attached photo is an QtpfsGUI tonemapping of a RAW image I took from the roof of our hotel one night. Istanbul is truly an amazing city and though this image doesn't exactly capture the experience of being there, I hope it captures something of the mood.

Thursday Mar 20, 2008

dtrace getenv and GNOME

While tracking down the root cause of intermittent hangs (often > 1 second) when traversing the panel menus on GNOME 2.20.1, I found some interesting things about how GNOME works. On one of my installs, the gtk-update-icon-cache hadn't been created correctly and doing anything which read an icon crashed the application (e.g. clicking on a panel menu.) This led to me to searching for the cause of this failure. I wanted to make sure gtk-update-icon-cache wasn't unnecessarily failing on assert The code looked O.K. but I thought I'd look at the system with dtrace. This led me to a nice putenv.d dtrace script. gtk-update-icon-cache doesn't seem to set G_DEBUG so that question is answered. But I decided to make a small change to script to look at getenv during a simple launch of eog. This gave me some interesting results:

bash-3.2$  dtrace -s ./getenv.d -c "eog" 

CPU     ID                    FUNCTION:NAME
  0  66661                     getenv:entry env[LANGUAGE]= LANGUAGE

  0  66661                     getenv:entry env[NLSPATH]= NLSPATH

  0  66661                     getenv:entry env[LANGUAGE]= LANGUAGE

  0  66661                     getenv:entry env[NLSPATH]= NLSPATH

  0  66661                     getenv:entry env[G_MESSAGES_PREFIXED]= G_MESSAGES
_PREFIXED

  0  66661                     getenv:entry env[G_DEBUG]= G_DEBUG

  0  66661                     getenv:entry env[CHARSET]= CHARSET

  0  66661                     getenv:entry env[LIBCHARSET_ALIAS_DIR]= LIBCHARSE
T_ALIAS_DIR

  0  66661                     getenv:entry env[G_RANDOM_VERSION]= G_RANDOM_VERS
ION

  0  66661                     getenv:entry env[LANGUAGE]= LANGUAGE
...
Then lots of redundant getenvs.
getenv LANGUAGE 1832 times 
getenv NLSPATH 1679 times
getenv TZ 432 times
aggregating on ustack shows that a good share of these come from these backtraces:
  getenv
              libc.so.1`getenv
              libc.so.1`getsystemTZ+0x1c
              libc.so.1`mktime+0x24
              libc.so.1`__strftime_std+0x3c
              libglib-2.0.so.0.1400.4`g_time_val_to_iso8601+0x60
              libglib-2.0.so.0.1400.4`timestamp_to_iso8601+0x24
              libglib-2.0.so.0.1400.4`bookmark_item_dump+0x68
              libglib-2.0.so.0.1400.4`g_bookmark_file_dump+0x16c
              libglib-2.0.so.0.1400.4`g_bookmark_file_to_data+0x70
              libglib-2.0.so.0.1400.4`g_bookmark_file_to_file+0xbc
              144
  getenv	
              libc.so.1`getenv
              libglib-2.0.so.0.1400.4`guess_category_value+0x24
              libglib-2.0.so.0.1400.4`g_get_language_names+0x68
              libglib-2.0.so.0.1400.4`g_key_file_locale_is_interesting+0x1c
              libglib-2.0.so.0.1400.4`g_key_file_parse_key_value_pair+0x2b8
              libglib-2.0.so.0.1400.4`g_key_file_parse_line+0x178
              libglib-2.0.so.0.1400.4`g_key_file_flush_parse_buffer+0x80
              libglib-2.0.so.0.1400.4`g_key_file_parse_data+0x104
              libglib-2.0.so.0.1400.4`g_key_file_load_from_fd+0x1fc

Now, here is the weird part. The application seems to continue polling getenv when you're on an active menu. I tried this with gnome-panel. The good news is that when I'm not touching panel, it doesn't seem to be polling environment variable. But when I hold the mouse over or traversed the launch menu, it continually tried to grab ESPEAKER and DISPLAY environment variables. These were all coming from this section of code:
             libc.so.1`getenv
              libesd.so.0.2.38`esd_open_sound+0x44
              libgnome-2.so.0.1999.2`use_sound+0x48
              libgnome-2.so.0.1999.2`gnome_sound_connection_get+0x18
              libgnomeui-2.so.0.2000.1`relay_gnome_signal+0x1cc
              libgobject-2.0.so.0.1400.4`signal_emit_unlocked_R+0x69c
              libgobject-2.0.so.0.1400.4`g_signal_emit_valist+0x784
              libgobject-2.0.so.0.1400.4`g_signal_emit+0x1c
              libgtk-x11-2.0.so.0.1200.3`gtk_widget_show+0xb8
              gnome-panel`panel_util_query_tooltip_cb+0x20
              libgtk-x11-2.0.so.0.1200.3`_gtk_marshal_BOOLEAN__INT_INT_BOOLE

Whoah, I had system sounds enabled for tooltips? I checked the preferences and sure enough system sounds were enabled. I never heard any so my audio hardware must not be supported. I still don't know for certain if this was the cause of the hang, since the hang was intermittent. But if you haven't tried it already, install GNOME on a machine with dtrace capability and look around a bit. If nothing else, you may learn something new.

Friday Mar 14, 2008

Workaround for nautilus/panel crashes in Nevada 84, 85.

A number of people have encountered a bug which causes nautilus and panel to crash on login, preventing the desktop from being used.

The symptoms are:
  • Nautilus crashes immediately on login, bringing up bug-buddy dialog.
  • Panel crashes immediately after the user clicks the Launch menu.
  • Any application which makes use of gtk icons crashes.

The bug is only experienced on some hardware and may not occur on every install even on hardware where it fails. It is caused by a file access race condition during the post install phase. The file access conflict causes an ASSERT in the gtk-update-icon-cache which forces this application to core during install. The user is left with incomplete and corrupt icon cache which causes failures of all applications depending on the gtk icon cache.

The bug is described in more detail here: 6631419 - gtk-update-icon-cache dies on first boot after install/upgrade

Fortunately, there is a very simple workaround:
  • Login as root
  • Run the following:
    for d in /usr/share/icons/\*; do
           [ -d $d ] &&
                   gtk-update-icon-cache --force $d;
    done
    

This bug is intermittent and is known to exist in Nevada build 84 and build 85. It may exist in earlier builds on some hardware. The GNOME community's decision to enable application cores on ASSERT may have made some of these subtle underlying problems suddenly become much more frequent and obvious. A fix for bug 6631419 is committed for Nevada build 86.

CORRECTION: There was a discussion over enabling fail on assert within the GNOME community, but no change was recently made. The behavior is that on unstable (odd numbered) versions of gnome-session, fail on assert is enabled, but on even numbered builds it isn't.

Monday Mar 19, 2007

About those SunLive07 Tech Days London public access terminals

For anyone who attended the SunLive07 Tech Days conference in London and attended talks and demos of Looking Glass, Wonderland and other cool new technology, you might have been disappointed in the look and feel and performance of the public access terminals upstairs. I can only say that the kiosk mode CDE running on what appeared to be an old version of Solaris with an old version of Sun Ray server does not look or perform nearly as well as anything beyond Solaris 10 with SRSS 3.0+. Here in Ireland I get about 1 Megabit broadband only when there is a tailwind. Yet the GNOME based JDS desktop in Solaris 10 or any recent Nevada build looks and works fine on a Sun Ray at my home. Some long time Solaris advocates perfer CDE on Solaris 8, but I'd put it in the same category as orange T-shirts. It would be really cool to have trusted JDS running on the public terminals. It's one of those technologies (like dtrace, ZFS...) that doesn't make for a flashy passive demo but once you've used it, you get it!
About

bnitz

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today