Since recent compiz updates in cooker, we have a "small" issue: the
window decoration plugin is not enabled correctly if the gconf
plugin is loaded in compiz, which we do by default (#32251).
Actually, it's a bug in the compiz part that initializes plugins.
It maintains a list of loaded plugins, and fills it at startup after
each successful plugin load. The problem is that the gconf plugin
also updates this list when initializing.
It happens this way: compiz first loads the glib plugin, adds it to
the plugins list, then loads the gconf plugin, which reads GConf
settings and notably loads the active_plugins GConf key in the
plugins list. And since the gconf plugin is loaded, compiz adds it
to the plugin list, but to the wrong place: it doesn't handle the fact
that a plugin could have modified the current plugins list
(more details in my post on the compiz ML).
I wrote a quick patch (see previous link) to make compiz handle the
fact that a plugin modifies the active plugins list, and it makes
compiz loads the decoration plugin fine. It has an unfortunate side
effect: the gconf plugin is not added in the active plugins list
anymore, and it make compiz segfaults when it is stopped.
To debug it further, I would have made gdb not stop on the SIGINT
signal and allow it to pass the signal to the debugged program
(gdb doc about signals):
(gdb) handle SIGINT nostop
(gdb) handle SIGINT pass
But I wasn't really able to catch the segfault this way, so I kinda
gave up. Anyway, this bug is not much important, we used to load the
gconf plugin by default, to make the default plugins stored in
gconf and to use the deprecated gset-compiz frontend. Now,
the default plugins list has been added by
coling in the core.xml file, so this is
not very useful anymore. (Hey, no, this wasn't a waste of time!)
Ok, there is a bug and I haven't issued a proper fix, but well, it
won't obsess me much. Furthermore, my
Asperger Quotient
is only 14, I'm not even up the so-called "average women" quotient.
So, why bother with this buglet? :-p
At that time, yesterday night, I thought that my day at the office was
offer, and that I could gently modify the compiz package from home,
not to load the gconf plugin by default. So, a bit later, I
leisurely updated my laptop at home with latest cooker, and prepared
to test my update package.
That was kinda naive, I should have known by now that the world is
full of bugs, and that they have a special kinship with me.
Of course, compiz didn't start correctly. Worse, it made my system
hard lock.
A quick look on freedesktop's bugzilla shows a bug with a close
description:
r300 DRI misrenders 3D objects (bug 11380).
In this report, the bug impacts blender. Ok, it's maybe a really long
shot. This bug seems to involve gcc and the -O2 build optimization,
especially the -ftree-vrp one
(upstream gcc bug 32544).
Yep, building with -O0 solves my bug \o/
Still, I couldn't let this miscompilation with -O2 unsolved.
So, the day after (today), I had a closer look to the incriminated
Mesa source code (src/mesa/drivers/dri/r300/r300_state.c).
Let's try the -fno-tree-vrp option mentionned in the bug report.
It works as well \o/
I extracted the code of the r300SetupPixelShader() function in a
separate r300_pixelshader.c file to make debugging
easier, since Bero already noticed it was the culprit (in the gcc bug
report).
First, the preprocessed files are the same:
gcc -O2 <options> r300_pixelshader.c -E -o r300_pixelshader.i
gcc -O2 -fno-tree-vrp <options> r300_pixelshader.c -E -o r300_pixelshader.notreevrp.i
Then, we can compare the generated assembly code (using
-fverbose-asm to get some hints):
gcc -fverbose-asm -O2 <options> r300_pixelshader.c -S -o r300_state.s
gcc -fverbose-asm -O2 -fno-tree-vrp <options> r300_pixelshader.c -S -o r300_state.s
It differs, maybe -fno-inline could have helped as well to reduce the diff,
but here I'm lost (see preprocessed diff on the freedesktop bug report).
Strangly enough, building with the -O3 optimize option instead of
-O2 also makes the r300 driver run fine.
According to the gcc manpage, -O3 is equivalent to
-O2 -finline-functions -funswitch-loops -fgcse-after-reload
A quick look at gcc's source code (decode_options() in gcc/opts.c)
seems to confirm that, but actually, a lot more options are enabled.
For example, some bits of loops unroll (from tree_complete_unroll()
in gcc/tree-ssa-loop.c) are enabled if optimize level is greater or
equal to 3. Building with
-O2 -finline-functions -funswitch-loops -fgcse-after-reload -funroll-loops
also made it work.
By the way, the code also runs fine when built with gcc 4.3.
This is all very interesting, but it does not help to find what's
breaking it between -00 and -O2, and it does not change the fact
that I'm lost /o\
Pixel, our beloved gcc maintainer in law, has helped me a lot so far,
and we were able to extract a not so big code portion (the assembly
diff is about 150 lines) that triggers the bug.
So let's give him the hot potato ;-)
Now, I'm sort of out of the loop, Pixel handles this fine. He has a
very small testcase (dozen of lines) that involves union variables and
Value Range Propagation (VRP) on trees, which can be debugged using
-fdump-tree-vrp, and gdb...
For now, I'm uploading a Mesa package built with -fno-tree-vrp in
cooker, we'll get a proper fix later if possible.
I can now focus on "desktop" features, expect a new drak3d soon!
