Google Chrome won't Start - Unable to locate theme engine in module_path: "adwaita"

The first part of my answer:

For GTK theme error: Unable to locate theme engine in module_path: "pixmap"

sudo apt-get install  gtk2-engines-pixbuf:i386

The problem appears to only happen with the i386 version of Google Chrome on a 64-bit Ubuntu system. The hint that it was a 32-bit vs 64-bit problem was that installing the :i386 version of certain packages made some errors go away. I was able to get Chrome working again by installing the 64-bit version:

$ sudo aptitude install google-chrome-stable

The following packages have unmet dependencies:
 libappindicator1 : Conflicts: libappindicator1:i386 but 12.10.1+15.04.20141110-0ubuntu1 is installed.
 libappindicator1:i386 : Conflicts: libappindicator1 but 12.10.1+15.04.20141110-0ubuntu1 is to be installed.
 google-chrome-stable : Conflicts: google-chrome-stable:i386 but 42.0.2311.152-1 is installed.
 google-chrome-stable:i386 : Conflicts: google-chrome-stable but 42.0.2311.152-1 is to be installed.
 libindicator7 : Conflicts: libindicator7:i386 but 12.10.2+14.10.20140922-0ubuntu1 is installed.
 libindicator7:i386 : Conflicts: libindicator7 but 12.10.2+14.10.20140922-0ubuntu1 is to be installed.
The following actions will resolve these dependencies:

     Remove the following packages:
1)     google-chrome-stable:i386   
2)     libappindicator1:i386       
3)     libindicator7:i386          

Accept this solution? [Y/n/q/?] 

I accepted the proposed solution to upgrade several packages to the 64-bit version, and Chrome is working again.

Cant always update the application, this worked for me

$ sudo apt install gnome-themes-standard:i386

I had this same problem, and mkasberg had the solution- to uninstall 32bit and reinstall 64bit. I had gone to google.com/chrome and downloaded the 64bit .deb as normal. I ran the .deb and google-chrome-stable was opened in the Software Center. Installed it, which went fine, but it turns out google-chrome-stable:i386 was installed instead.

$ sudo apt-get remove google-chrome-stable:i386
$ sudo apt-get install google-chrome-stable

I was using a gtk install with prefix /usr/src/ClawsMail/install. The above warning is printed after (strace) printing:

access("/home/carlo/.gtk-2.0/2.10.0/x86_64-pc-linux-gnu/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/home/carlo/.gtk-2.0/2.10.0/x86_64-pc-linux-gnu/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/home/carlo/.gtk-2.0/2.10.0/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/home/carlo/.gtk-2.0/2.10.0/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/home/carlo/.gtk-2.0/x86_64-pc-linux-gnu/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/home/carlo/.gtk-2.0/x86_64-pc-linux-gnu/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/home/carlo/.gtk-2.0/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/home/carlo/.gtk-2.0/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/ClawsMail/install/lib/gtk-2.0/2.10.0/x86_64-pc-linux-gnu/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/ClawsMail/install/lib/gtk-2.0/2.10.0/x86_64-pc-linux-gnu/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/ClawsMail/install/lib/gtk-2.0/2.10.0/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/ClawsMail/install/lib/gtk-2.0/2.10.0/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/ClawsMail/install/lib/gtk-2.0/x86_64-pc-linux-gnu/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/ClawsMail/install/lib/gtk-2.0/x86_64-pc-linux-gnu/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/ClawsMail/install/lib/gtk-2.0/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/ClawsMail/install/lib/gtk-2.0/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/2.10.0/x86_64-pc-linux-gnu/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/2.10.0/x86_64-pc-linux-gnu/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/2.10.0/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/2.10.0/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/x86_64-pc-linux-gnu/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/x86_64-pc-linux-gnu/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/engines/libadwaita.so", F_OK) = -1 ENOENT (No such file or directory)
access("/usr/lib/gtk-2.0/engines/libadwaita.la", F_OK) = -1 ENOENT (No such file or directory)

Assuming it is normal that nothing is found in my home directory, and because my installation in /usr/src/ClawsMail/install is abnormal, I am assuming that normally libadwaita.so would be found <prefix>/lib/gtk-2.0/..., but that I did not install libadwaita under the same prefix.

HOWEVER - after looking in /usr/src/ClawsMail/install it goes on looking in /usr/lib/gtk-2.0/... so that should not make a difference if the normal install is under /usr.

I DO have libadwaita.so installed on my system, and well here:

/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/libadwaita.so

Note that /usr/lib/gtk-2.0 doesn't even exist.

It turns out that this search happens during the call to

_gtk_find_module (name=0x5555557ee0e0 "adwaita", type=0x7ffff7b0c776 "engines") at gtkmodules.c:196

and that the paths searched are those returned by

paths = _gtk_get_module_path (type);

which gets the three prefixes from

gchar **paths = get_module_path();

It turns out that the last prefix (/usr/lib/gtk-2.0) is dubbed the pre_multiarch_dir, aka the prefix before multiarch; which is indeed not used anymore.

My problem is therefore that I do not have the engines installed in the same prefix as where I installed gtk-2.0. However, the search can be extended with environment variables:

If GTK_EXE_PREFIX is set then $GTK_EXE_PREFIX/lib/gtk-2.0 will be used instead of the install prefix of gtk-2.0 itself and the pre_multiarch_dir (so not useful on a modern multiarch dist).

If GTK_PATH is set then that will be used on top of everything else. I believe the latter can even be a semicolon separated list of paths.

Using

export GTK_PATH="/usr/lib/x86_64-linux-gnu/gtk-2.0"

therefore, made the warning go away for me.

For Kubuntu 20.04 this worked for me (had this error when trying to run JavaFX app):

sudo apt install gnome-themes-standard

I've had this annoying warning/error for a long time, on one of my CentOS-7 boxes. (Probably same reason for Ubuntu, I expect).

Finally tracked it down today. In the Gtk-2.0 directory, the dynamic lib file: "libadwaita.so" was missing. I would get this warning message, everytime I started a Gnome/X11 window application:

Gtk-WARNING **: ... Unable to locate theme engine in module_path: "adwaita"

The "libadwaita.so" file has to be placed into directory:

/usr/lib64/gtk-2.0/2.10.0/engines

The theme "adwaita" appears to be the Gnome default, and in some earlier Gnome installs, the dynamic lib file was just not getting dropped into the right location. On the machine which gave the warning-error, I only had two files: "liboxygen-gtk.so" and "libpixmap.so", whereas the no-problem box had all three lib files. I resolved the warning-error message by simply copying the correct "libadwaita.so" lib to the above Gtk-2.0 "engines" directory. No other changes needed. Note: I had all the Gnome themes, engines and so on, installed, with latest versions. Linux kernel is 4.4.185-1.

I have just built a Glade/GTK-2.0 application, using C, and two instances of this annoying warning-error would appear, every time it was started. Everything worked ok, but the warning-error would pop-up on the invoking xterm window in bright-yellow highlighted text, which made it appear there was a problem with my application, so I had to track down this issue today. Hope this info helps.