Closed Bug 841970 Opened 11 years ago Closed 11 years ago

Ubuntu ec2 VMs tests sometimes run without Ambience theme

Categories

(Testing :: General, defect)

Product:
Testing
Component:
General
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: karlt, Unassigned)

References

(Blocks 1 open bug)

Details

The Ubuntu64 crashtests at https://tbpl.mozilla.org/?tree=Try&rev=4c6ced6403d2 are actually the forms reftests.

On the fifth crashtest run, textarea-resize-background fails and textarea-rtl passes.  The image shows a resizer that matches the resizer from GTK's default theme.  Ambience is the theme expected, and that seems to be used on other runs.
Summary: Ubuntu ec2 VMs tests sometime run without ambience theme → Ubuntu ec2 VMs tests sometimes run without Ambience theme
Wild speculation: could the Firefox process be starting before the desktop session has properly started?  Perhaps the desktop session hasn't yet read preferences and initialized the settings daemon.
hmm, that could be possible, it seems that when we launch the job, we have about 50 seconds before we launch Firefox.  We work so hard to reduce our setup/cleanup time per job, maybe on these VMs we need to slow it down a minute?
I don't know.  50 seconds sounds like a long enough time.  And GTK is meant to notice when the X Settings daemons starts up and respond by dynamically applying the configured theme.  Even tests that run later are using the wrong theme engine.

Looking through crash reports on cedar, libmurrine.so (used by Ambience) is not loaded in the runs where screenshots do not have Firefox looking like Ambience. e.g.
https://tbpl.mozilla.org/php/getParsedLog.php?id=19916675&full=1&branch=cedar#error1

When libmurrine.so is not loaded, libcanberra-gtk-module.so is also not loaded, suggesting a general problem with gtk modules.
I wonder if there is a problem with some of the vms we are using?  is there a different between 64 or 32 bit and how the themes/gtk are used or initialized?
(In reply to Joel Maher (:jmaher) from comment #4)
> I wonder if there is a problem with some of the vms we are using?  is there
> a different between 64 or 32 bit and how the themes/gtk are used or
> initialized?

They should be identical. Both 32 and 64-bit installed and puppetized using the same scenario. The only difference is ia32-libs installed on 64-bit vms.
The issue occurs on both 32 and 64-bit machines and bug 834724 comment 36 noticed that the same VM was behaving inconsistently.
how can I detect which theme is running?  I have a second (loaner) ubuntu 64 bit vm and it fits this model.  The window controls  (minimize, maximize, close) are on the right hand side whereas on my desktop they are on the left hand side.

I looked at the system settings and it is set to use ambiance on both systems.
In Ambience, the Firefox menubar and background tabs have a dark brown background.
The default GTK theme has a light grey background, but screenshots showing this bug have a light brown or cream background, perhaps indicating that Ambience is partially active or another theme altogether is in use.

Don't look at the window manager frame, with the minimize maximize and close.  The title bar should be dark brown with Ambience, but it is even when Firefox is not using the Ambience theme.  This is because the window manager process draws the titlebar and window frame.

I don't know a good way to query the system theme.

For a process that is running, I suggest checking for output of "lsof -c firefox | grep libmurrine.so", assuming there is only one firefox process.  If that gives no output then Ambience is not properly used.
It looks like the icon theme is also different.

When Ambience is used the new tab button has a green plus icon.  With the other theme, perhaps the GTK builtin theme, the plus icon is blue.  The reload, back, and home buttons are also different.

The icon theme is not different in the window manager nor in the system panels.
https://tbpl.mozilla.org/?tree=Try&rev=caeba0f48fb9 contains some logging at Firefox startup to log whether there is an X settings server running.

There is an X settings server running when Ambience is used, but there is not when the other theme is used.  The environment variables look very similar is each case.
It looks like gnome-settings-(daemon) is either not being started or has terminated prematurely.

https://tbpl.mozilla.org/?tree=Try&rev=af36dd582af5 logs at Firefox startup and shutdown whether there is an X settings server running as well as the list of processes.  There is about 1 minute between startup and shutdown, but there are no cases where the settings server becomes present between startup and shutdown.

Is there any output from gnome-settings-daemon in the log?

https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/649809 seems like a common bug.
(In reply to Karl Tomlinson (:karlt) from comment #11)
> Is there any output from gnome-settings-daemon in the log?

I mean in ~/.xsession-errors
https://tbpl.mozilla.org/?tree=Try&rev=2c82cf9c8a9b

3:42:48     INFO -  (gnome-settings-daemon:1729): GLib-GIO-WARNING **: Error releasing name org.gnome.SettingsDaemon: The connection is closed
23:42:48     INFO -  (gnome-settings-daemon:1729): GLib-GObject-WARNING **: invalid (NULL) pointer instance
23:42:48     INFO -  (gnome-settings-daemon:1729): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
23:42:48     INFO -  (gnome-settings-daemon:1729): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
23:42:48     INFO -  (gnome-settings-daemon:1729): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
23:42:48     INFO -  (gnome-settings-daemon:1729): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
23:42:48     INFO -  (gnome-settings-daemon:1729): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
23:42:48     INFO -  (gnome-settings-daemon:1729): GLib-CRITICAL **: g_ptr_array_unref: assertion `array' failed
23:42:48     INFO -  (gnome-settings-daemon:1729): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
23:42:48     INFO -  (gnome-settings-daemon:1729): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
23:42:48     INFO -  (gnome-settings-daemon:1729): power-plugin-CRITICAL **: gpm_idletime_alarm_remove: assertion `GPM_IS_IDLETIME (idletime)' failed
23:42:48     INFO -  (gnome-settings-daemon:1729): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
23:42:48     INFO -  (gnome-settings-daemon:1729): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

23:42:48     INFO -  (gnome-settings-daemon:1729): print-notifications-plugin-CRITICAL **: gsd_print_notifications_plugin_finalize: assertion `plugin->priv != NULL' failed

23:42:48     INFO -  x-session-manager[1493]: WARNING: Application 'gnome-settings-daemon.desktop' killed by signal
Is gnome-settings-daemon quitting on startup?

23:42:48     INFO -  g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
Of course, it's obvious that it is :)

What image are these VM's created from?
What version of gnome-settings-daemon are you using? I just set up a fresh precise chroot, tried to start a session from it and immediately hit a gnome-settings-daemon crash which is fixed by this commit if you update to the latest gnome-settings-daemon version from the precise-updates pocket:

http://git.gnome.org/browse/gnome-settings-daemon/commit/?h=gnome-3-4&id=70cc6e74ef0f14b1c137b7a756a855b3d18c7576
ii  gnome-settings-daemon                  3.4.1-0ubuntu1


I assume that isn't the one from the precise-updates, I can try that out tomorrow morning!
Excellent, thanks. That should solve it :)
hmm, how do I do this?  I am not familiar with updates and a google search didn't help me figure it out.
Does "apt-cache policy gnome-settings-daemon" show a newer candidate version than the currently installed version? If it does, then you should just be able to run "apt-get upgrade". If not, then you're probably missing the source for the updates pocket.

What apt sources do you currently have set up in /etc/apt/sources.list? Assuming you're pulling packages from the main archive, you should already have an entry for the release pocket that looks something like this:

deb http://archive.ubuntu.com/ubuntu precise main restricted

"precise" is the distribution, and "main restricted" is a whitespace separated list of components. I'm not sure which components you enable, although I guess you probably only really need main. The supported components are "main", "restricted", "universe" and "multiverse".

To enable updating from the updates pocket, you would need another entry similar to above, but setting the distribution to "precise-updates":

deb http://archive.ubuntu.com/ubuntu precise-updates main restricted

You should also have a similar entry for the security pocket ("precise-security")
# apt-cache policy gnome-settings-daemon
gnome-settings-daemon:
  Installed: 3.4.1-0ubuntu1
  Candidate: 3.4.1-0ubuntu1
  Version table:
 *** 3.4.1-0ubuntu1 0
        500 http://repos/repos/apt/ubuntu/ precise/main i386 Packages

# cat /etc/apt/sources.list /etc/apt/sources.list.d/*
# Managed by puppet
# Managed by puppet
deb http://repos/repos/apt/ubuntu precise main restricted universe
# Managed by puppet
deb http://repos/repos/apt/ubuntu precise-security main restricted universe
# Managed by puppet
deb http://repos/repos/apt/releng precise main

No entry for precise-updates.
FTR, if we need packages from precise-updates, I'll need to file an IT bug to mirror those. Shouldn't be a problem unless precise-updates is very huge.
rail, did you figure out where to get this update from?
Chris, is there any information that we are overlooking?
(In reply to Joel Maher (:jmaher) from comment #23)
> rail, did you figure out where to get this update from?

I'll file a bug to mirror the precise-updates component.
Depends on: 846346
Depends on: 846348
(In reply to Joel Maher (:jmaher) from comment #23)
> rail, did you figure out where to get this update from?
> Chris, is there any information that we are overlooking?

No, I suspect that once precise-updates is mirrored and gnome-settings-daemon is updated, this should just start working :)
joel, can you try to run the following commands to update the package and see if it helps?

# as root
echo "deb http://archive.ubuntu.com/ubuntu precise-update main restricted universe" >> /etc/apt/sources.list
apt-get update
apt-get install gnome-settings-daemon

You can verify the installed version:
dpkg -l gnome-settings-daemon
this doesn't seem to find a new package:

root@tst-jmaher-ubuntu64-009:/home/cltbld/jmaher# apt-get install gnome-settings-daemon
Reading package lists... Done
Building dependency tree       
Reading state information... Done
gnome-settings-daemon is already the newest version.
gnome-settings-daemon set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 119 not upgraded.
root@tst-jmaher-ubuntu64-009:/home/cltbld/jmaher# dpkg -l gnome-settings-daemon
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                       Version                    Description
+++-==========================-==========================-====================================================================
ii  gnome-settings-daemon      3.4.1-0ubuntu1             daemon handling the GNOME session settings
root@tst-jmaher-ubuntu64-009:/home/cltbld/jmaher# cat /etc/apt/sources.list
# Managed by puppet
deb http://archive.ubuntu.com/ubuntu precise-update main restricted universe
root@tst-jmaher-ubuntu64-009:/home/cltbld/jmaher#
(In reply to Rail Aliiev [:rail] from comment #26)
> # as root
> echo "deb http://archive.ubuntu.com/ubuntu precise-update main restricted universe" >> /etc/apt/sources.list

Ooops, typo: s/update/updates/
aye, that does the trick!
It's working ok now?
the theme is solid across reboots when before it was always visibly wrong.
we have updated our VMs with the latest gnome-settings-daemon, I am going to resolve this as fixed.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Component: Infrastructure → General
You need to log in before you can comment on or make changes to this bug.