compiz - May 2007 - compiz segfaults on starting second X server / suspend to ram

Hello,
when I start a second X server or when I suspend (and resume) to ram 
compiz crashes.
I tryed to debug this but its impossible to run gdb on compiz (=freeze). 
This happens with current git, but If I remember correctly not with 
0.3.6 (and git versions < 0.5.0 but I don't know when it started to
happen).
any ideas?

> Hello,
> when I start a second X server or when I suspend (and resume) to ram 
> compiz crashes.
> I tryed to debug this but its impossible to run gdb on compiz (=freeze). 
> This happens with current git, but If I remember correctly not with 
> 0.3.6 (and git versions < 0.5.0 but I don't know when it started to
happen).
> any ideas?
It is possible to debug compiz using gdb, you just can't run gdb in a
terminal drawn by compiz. The simplest way is to
run it remotely through ssh. If you don't have another computer at your
disposal, it's still possible to run gdb+compiz
on another VT, but you'll need to utilize the kernel's "Magic SysRq
key" to escape from the freeze (to get back to the
console). You can find more info on both ways (plus one more which doesn't
seem to be much reliable) on these links:

http://forum.compiz.org/viewtopic.php?p=111
http://www.ubaight.com/pipermail/compcomm/2007-May/000639.html

[Thanks to the author of the latter post! I haven't heard about the key
combination before.]

I'd add that the SysRq key combinations may not be available by default, it
depends on kernel compiling configuration
and it can be turned on/off in addition. I don't know the various kernels,
see your kernel documentation for details.
For example, on my Fedora Core 6, the support is compiled in, but must be turned
on as described in
/usr/share/doc/kernel-doc-2.6.20/Documentation/sysrq.txt.
And the situation is still a bit more tricky with nVidia because of its
"VT-switching bug" (I may be wrong here), I
solved this by switching to the X VT very very fast after the run command :-)

On Thu, 2007-05-17 at 01:25 +0200, Vasek Potocek wrote:
> > Hello,
> > when I start a second X server or when I suspend (and resume) to ram 
> > compiz crashes.
> > I tryed to debug this but its impossible to run gdb on compiz
(=freeze).
> > This happens with current git, but If I remember correctly not with 
> > 0.3.6 (and git versions < 0.5.0 but I don't know when it
started to happen).
> > any ideas?
> 
> It is possible to debug compiz using gdb, you just can't run gdb in a
terminal drawn by compiz. The simplest way is to
> run it remotely through ssh. If you don't have another computer at your
disposal, it's still possible to run gdb+compiz
> on another VT, but you'll need to utilize the kernel's "Magic
SysRq key" to escape from the freeze (to get back to the
> console). You can find more info on both ways (plus one more which
doesn't seem to be much reliable) on these links:
> 
> http://forum.compiz.org/viewtopic.php?p=111
> http://www.ubaight.com/pipermail/compcomm/2007-May/000639.html
> 
> [Thanks to the author of the latter post! I haven't heard about the key
combination before.]
> 
> I'd add that the SysRq key combinations may not be available by
default, it depends on kernel compiling configuration
> and it can be turned on/off in addition. I don't know the various
kernels, see your kernel documentation for details.
> For example, on my Fedora Core 6, the support is compiled in, but must be
turned on as described in
> /usr/share/doc/kernel-doc-2.6.20/Documentation/sysrq.txt.
> And the situation is still a bit more tricky with nVidia because of its
"VT-switching bug" (I may be wrong here), I
> solved this by switching to the X VT very very fast after the run command
:-)
Most of the time it's enough to have compiz dump a core file and load it
in gdb to see what caused a crash. I use this 95% of the time to track
down crashes in compiz.

- David