I reinstalled compiz from git, and now it segfaults...

[enigma_0Z]

I reinstalled compiz by compiling from git via makefusiondebs, and now it segfaults. Just in case of such a situation, I kept my old debs, but now even my older packages segfault!

With either package, I get output similar to "compiz line 775: segmentation fault".

Line 775 in the wrapper script is a process launching function... but there is a "compiz.real" that has been executed....

I'm really pulling my hair out now, does anyone know what could be going on?

[Deciare]

Try disabling every plugin to see if it still crashes? Even if that doesn't stop the crashing, we would have eliminated the possibility that plugins carried over from your earlier Compiz installation might be causing problems.

[enigma_0Z]

Actually... I was downgrading wrong. I downgraded to a version compiled on *goes off to look* 11-15-07.

As far as removing all old plugins and whatnot, I'll try it, but what I did to test is simply:

1. Move .config/compiz elsewhere
2. Move .compiz elsewhere as well

AFAIK that would have the effect of a "clean start", right?

And, find -iname '*compiz*' /usr only turns up important stuff in /usr, not /usr/local. And when I remove compiz, that turns up empty except for a small python script in /usr/local.

What I don't get is why there isn't more useful output that "Segmentation fault (core dumped)". This may sound stupid, but where would the core dump file go?

Thanks.

--edit--

This has been going on wince 11-15-07, my next build (a couple days later) also borked in the same way. I'm using makefusiondebs to build them and normally use the "nopatch" option just because I'm paranoid... I have XCB installed and the last run may have applied the no XCB patch, could that be it? I'm not entirely sure what patches trevino was applying to compiz with his script.

[Deciare]

Actually... I was downgrading wrong. I downgraded to a version compiled on *goes off to look* 11-15-07.
Downgrading wrong in what way?

As far as removing all old plugins and whatnot, I'll try it, but what I did to test is simply:

1. Move .config/compiz elsewhere
2. Move .compiz elsewhere as well

AFAIK that would have the effect of a "clean start", right?
In some cases, yes. However, moving ~/.compiz away will not resolve issues with conflicting versions of plugins installed into /usr.

Nor would moving ~/.config/compiz out of the way resolve potential configuration issues with the GConf or KConfig configuration backends. You should remove ~/.kde/share/config/compiz* in the case of KConfig, and run
gconftool-2 --recursive-unset /apps/compiz in the case of GConf.

What I don't get is why there isn't more useful output that "Segmentation fault (core dumped)". This may sound stupid, but where would the core dump file go?
If Compiz gets far enough into the startup process to load any plugins (that's what I was asking you to test by disabling every plugin and re-enabling them one at a time), then the crashhandler plugin should print a debug trace as well as save a copy of it into the /tmp directory.

This has been going on wince 11-15-07, my next build (a couple days later) also borked in the same way. I'm using makefusiondebs to build them and normally use the "nopatch" option just because I'm paranoid... I have XCB installed and the last run may have applied the no XCB patch, could that be it? I'm not entirely sure what patches trevino was applying to compiz with his script.
Compiz doesn't currently make much use of X11-XCB, so I doubt that would be a problem. However, if any of your plugins were compiled against an unpatched version of Compiz, then you should definitely rebuild your plugins against the version you currently have installed.

[enigma_0Z]

Downgrading wrong in what way?

I have several different sets of debs that I've made, I was simply installing older debs that I had packaged. I've got a set of debs, but zero knowhow on what version they should be and no hosting to put them for others to download (from a repo) :(


In some cases, yes. However, moving ~/.compiz away will not resolve issues with conflicting versions of plugins installed into /usr.

Nor would moving ~/.config/compiz out of the way resolve potential configuration issues with the GConf or KConfig configuration backends. You should remove ~/.kde/share/config/compiz* in the case of KConfig, and run
gconftool-2 --recursive-unset /apps/compiz in the case of GConf.

Hmm... I think the gconftool-2 command fixed it for me, because it is working now...

If Compiz gets far enough into the startup process to load any plugins (that's what I was asking you to test by disabling every plugin and re-enabling them one at a time), then the crashhandler plugin should print a debug trace as well as save a copy of it into the /tmp directory.

OK. I'll look for that next time I have an issue. AFAIK it did something like that before, b ut this time it (obviously) wasn't happening.

Compiz doesn't currently make much use of X11-XCB, so I doubt that would be a problem. However, if any of your plugins were compiled against an unpatched version of Compiz, then you should definitely rebuild your plugins against the version you currently have installed.

a bit offtopic, but what does compiz use XCB for? Because, when I run the patched version of compiz (once again, I'm not entirely sure what patches are being applied) AWN's icon captions leave little bits of black garbage on the screen... but with the "nopatch" option, everything's clean.

Anyways, thanks for the help!

[Deciare]

a bit offtopic, but what does compiz use XCB for? Because, when I run the patched version of compiz (once again, I'm not entirely sure what patches are being applied) AWN's icon captions leave little bits of black garbage on the screen... but with the "nopatch" option, everything's clean.
Honestly? I don't know. :p It's just... Given how easy it is to patch it out, if these instructions are still accurate (http://forum.compiz-fusion.org/showpost.php?p=35991&postcount=9), then the only thing Compiz does it with is connect to the X server.

Maybe the fact of using an Xlib-XCB connection is somehow better than using a plain Xlib connection. I really don't know enough about this subject to elaborate.