I think compiz is multi-threaded... so you have to take backtrace from all threads. "info stack" works for current selected thread only.
With "info stack" you can enumerate all the running threads of the application that you debug. if you execute inside gdb "info stack" you ll something like this in case that it has 4 threads running.: (gdb) info thread 4 Thread 0xb6c65b90 (LWP 12520) 0xb7f05410 in __kernel_vsyscall () 3 Thread 0xb7466b90 (LWP 12519) 0xb7f05410 in __kernel_vsyscall () 2 Thread 0xb7c67b90 (LWP 12518) 0xb7f05410 in __kernel_vsyscall () * 1 Thread 0xb7c68940 (LWP 12510) 0xb7f05410 in __kernel_vsyscall () The * shows which is the active. "info stack" will show the stack trace only from the active thread. By executing "thread <no>" you make another thread active. e.g. "thread 3" will make active the 3rd thread from the list you saw. Running again "info stack" you ll get the stacktrace from thread 3 now. Finally if you manage to lock it up again, check if it has multiple threads running and if they are, take stack trace from all of them. This may be the reason you get different stack traces, you traces from different threads, although the second seems corruptes as it starts from 0x00000000. I am not a compiz expert, but I may have a change to be right. hope to helped ** Attachment added: "unnamed" http://launchpadlibrarian.net/13586115/unnamed -- compiz randomly freezes X https://bugs.launchpad.net/bugs/176589 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
