[Ayatana-dev] [SOLVED] Re: [Compiz] Unity failing to load

[Tim Penhey <tim.penhey@xxxxxxxxxxxxx>]

Problem solved, and since it was such a pain, and no one seemed to know, I 
thought I'd share the solution.

On Mon, 01 Aug 2011 13:23:13 Tim Penhey wrote:
> Hi people,
> 
> I'm probably doing something stupid, but I'm not sure what it is.

It was stupid.  Kudos to Jason for helping me install debug packages [1] as to 
step through in gdb.

> function unity-env
> {
>   export PATH=~/staging/bin:$PATH
>   export XDG_DATA_DIRS=~/staging/share
>   export LD_LIBRARY_PATH=~/staging/lib:$LD_LIBRARY_PATH
>   export LD_RUN_PATH=~/staging/lib:$LD_RUN_PATH
>   export PKG_CONFIG_PATH=~/staging/lib/pkgconfig
>   export PYTHONPATH=~/staging/lib/python2.7/site-packages
> }
> 
> Anyone got any clues?

It was suggested that I change the exports to include the existing directories 
when there were some, so this was updated to:

   export PATH=~/staging/bin:$PATH
   export XDG_DATA_DIRS=~/staging/share:${XDG_DATA_DIRS}
   export LD_LIBRARY_PATH=~/staging/lib:${LD_LIBRARY_PATH}
   export LD_RUN_PATH=~/staging/lib:${LD_RUN_PATH}
   export PKG_CONFIG_PATH=~/staging/lib/pkgconfig:${PKG_CONFIG_PATH}
   export PYTHONPATH=~/staging/lib/python2.7/site-packages:$PYTHONPATH

However that made zero difference.

I installed libgdk-pixbuf2.0-dev-dbgsym (and libgdk-pixbuf2.0-dbgsym, not sure 
if I needed both), and then grabbed the source using:
   $ apt-get source libgdk-pixbuf2.0-dev
in my ~/sandbox directory.

I then debugged compiz in vt2 using
  $ gdb compiz -d ~/sandbox/gdk-pixbuf-2.23.5/gdk-pixbuf [2]
Prior to running, did
  b PlacesStyle::TextureFromFilename [3]
  run --replace

Then I stepped into the gdk_pixbuf_new_from_file call.  This lead me into some 
gio functions which were not returning the correct module.  So off to install 
the debug symbols for libglib-2.0 and the souce.

I finally stepped into a suspect looking piece of code that was checking 
XDG_DATA_DIRS.  It was just prior to this where I was starting to step through 
methods starting with xdg_ that I was starting to get some clue as to what was 
going on as I had remembered that XDG_DATA_DIRS was being updated.

I had been also stepping through and debugging a very simple app that Neil 
Patel wrote for me to test the function locally 
(http://paste.ubuntu.com/656253/), but that one was working.  Also that call 
never got to anything checking XDG_DATA_DIRS, only XDG_DATA_HOME [4]

The offending area of code is
  /glib2.0-2.29.14/gio/xdgmime/xdgmime.c line 258

>  xdg_data_dirs = getenv ("XDG_DATA_DIRS");
>  if (xdg_data_dirs == NULL)
>    xdg_data_dirs = "/usr/local/share/:/usr/share/";

Now... lets look again at what I had.
   export XDG_DATA_DIRS=~/staging/share:${XDG_DATA_DIRS}

My system compiz and unity environment worked fine because this environment 
variable was not set at all.  So in those situations it used 
"/usr/local/share/:/usr/share/".  However when I tried to add something to 
this environment variable, I had

  $ echo ${XDG_DATA_DIRS}
  /home/tim/staging/share:

Which is clearly not NULL..  I updated my function to set the environment to 
instead say:
   export XDG_DATA_DIRS=~/staging/share:/usr/local/share/:/usr/share/

And then it is all working lovely.

Lessons learnt:
 * gdb, while awesome, is a real pain to do a lot of stepping through
 * installing debug symbols isn't enough to step through code in gdb
 * apt-get source rocks
 * special default locations *should* (IMO) be additive


I hope some of you find this useful.

Tim

[1] https://wiki.ubuntu.com/DebuggingProgramCrash, steps 1, 3 and 4
[2] -d (or directory once inside gdb) gives gdb another location to look for 
files.
[3] Even thought the library isn't loaded, gdb will let you set a pending 
breakpoint which it checks on loading libraries.
[4] This is a guess, but there is an env setting XDG_SESSION_COOKIE which I'm 
guessing is used across process for shared memory access to standard mimetype 
stuff, hence the local app not looking through XDG_DATA_DIRS

Attachment: signature.asc
Description: This is a digitally signed message part.