Hello all

I made a theme in aurorae but if it's set as default for the iso it maxes out the cpu and freezes the system.
I heard about kwin not being native friendly for graphics and to switch it to raster instead.
Will this solve the issue?
If so where do I make this change?
Running oxygen is no problem just when running a window decoration made with aurorae.
On an installed system there is no issue with aurorae, just running it from a live cd causes this issue.

Any help would be greatly appreciated
Thanks in advance
Sam

Are you able to attach a debugger to KWin to see what it is doing? As KWin is usually compositing the desktop, you'll need to do this from another computer, and access the system running the Live CD via SSH or similar.

bcooksley wrote:Are you able to attach a debugger to KWin to see what it is doing? As KWin is usually compositing the desktop, you'll need to do this from another computer, and access the system running the Live CD via SSH or similar.

Would you know how to set up a debugger to KWin to see what's going on or lead me to a place to show me how to do this?

Any help would be greatly appreciated.

Thank you in advance
Sam

Debugging KWin is like any other application - except, because it is a window manager, you will need to connect to the machine where you are running KWin from another system using SSH, and run the debugger over that.

GDB can be used for doing this. Please see https://wiki.debian.org/HowToGetABacktrace for more information on generating backtraces.

Thank you very much for this information.
I really appreciate it.

Sam

This is what I've come up so far:

VirtualBox : Settings : Network
============================================
NAT -> Bridged Network

In guest (SolydK live)
============================================
sudo apt-get install openssh-server gdb
sudo ufw disable
sudo ifconfig (save IP)

In host
============================================
ssh solydxk@192.168.1.3
ps -ef | grep kwin (get the pid of /usr/bin/kwin)
DISPLAY=:0 gdb kwin 4691
>> it now freezes <<
bt
>> still frozen <<

Output
============================================
http://pastebin.com/wC41vyjc

But I don't see that the output has any relevance.
Did I miss something?

When you attach gdb the application you attached to freezes. To unfreeze it, type "continue".

Okay, after the "continue" (gdb showed "Continuing"), the system was responsive again.
When trying to change theme, the system froze again, and gdb did not show any output, and I couldn't type any gdb command.
This was the moment I hoped to get some backtrace output.

How do I continue?

Hit Ctrl+C in the gdb shell to make gdb interrupt the application again. Then type "thread apply all bt" to print the backtrace info, and "continue" to continue.

Greetings!

Before changing themes, I ran "thread apply all bt":

Code: Select all

Thread 2 (Thread 0x7fc04df15700 (LWP 4694)):
#0  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007fc06a5b4b3b in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4
#2  0x00007fc06a5b4b79 in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4
#3  0x00007fc063b66e0e in start_thread (arg=0x7fc04df15700) at pthread_create.c:311
#4  0x00007fc06b3b30fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 1 (Thread 0x7fc06bbce880 (LWP 4692)):
#0  0x00007fc06b3abf53 in select () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fc0661a9157 in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timeval const*) ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#2  0x00007fc0661ae784 in QEventDispatcherUNIXPrivate::doSelect(QFlags<QEventLoop::ProcessEventsFlag>, timeval*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#3  0x00007fc0661aebf2 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#4  0x00007fc0655be086 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#5  0x00007fc06617d03f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#6  0x00007fc06617d335 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#7  0x00007fc066182b09 in QCoreApplication::exec() ()
   from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#8  0x00007fc06b6ef606 in kdemain () from /usr/lib/kde4/libkdeinit/libkdeinit4_kwin.so
#9  0x00007fc06b2eb995 in __libc_start_main (main=0x4006e0, argc=2, ubp_av=0x7fff6abbe548,
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
    stack_end=0x7fff6abbe538) at libc-start.c:276
#10 0x000000000040070e in _start ()


When the system froze, a Ctrl-C didn't do a thing, I'm afraid.

If anyone's interested, I prepared an ISO for this test: http://downloads.solydxk.com/dev/solydk ... _theme.iso
Boot it in Virtualbox, and SSH with: solydxk@[ip], pwd = solydxk

Ctrl+C in the debugger shell should enable you to enter a command there. Doesn't it?

No, Ctrl-C doesn't do a thing in the debugger, as soon as the guest freezes.

Never seen that. Maybe that means the graphics driver itself freezes?

scummos wrote:Never seen that. Maybe that means the graphics driver itself freezes?

I was thinking that as well, but it only happens in VirtualBox in a live environment.
I was never even able to install the system in VB: it freezes before the installation finishes.

Thanks for your help, though.

Can you try pinging the frozen virtual machine, to see if the kernel is still functional?