Comment 9 for bug 403154

I was able to reproduce this and determine which thread is spinning.

New project, add one clip (AVCHD H.264 MPEG-TS 24mbps from Canon HF11). Put clip in Track #1. Drag time-cursor back and forth in the time-line until one core of the CPU hits 100% and stays there.

This happens whether or not audio is muted.

At the same time in a terminal I ran:

ps -em -o pcpu,lwp,stat,pid,tid,class,psr,wchan,args

The output related to openshot is:

62.0 - - 13243 - - - - /usr/bin/python -m pdb /usr/bin/openshot
 0.4 13243 Sl+ - 13243 TS 0 futex_ -
 0.0 13252 Sl+ - 13252 TS 0 futex_ -
 0.0 13254 Sl+ - 13254 TS 0 futex_ -
 0.0 13255 Sl+ - 13255 TS 0 futex_ -
 0.0 13453 Sl+ - 13453 TS 1 futex_ -
 0.2 13454 Sl+ - 13454 TS 0 futex_ -
 0.0 13455 Sl+ - 13455 TS 0 poll -
63.0 13456 Rl+ - 13456 TS 0 - -
 0.0 13457 Sl+ - 13457 TS 0 futex_ -

Note lightweight thread #13456 at 63% (2 cores =100% so that's 1 core at least)

With openshot running under gdb debugging I then interrupted the process (Ctrl+C) and listed the threads and compared that output:

(gdb) infor threads

(gdb) info threads
  59 Thread 0x7f29971b6950 (LWP 13457) pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  58 Thread 0x7f29a2ff0950 (LWP 13456) 0x00007f29ac63e1da in ?? () from /usr/lib/libasound.so.2
  57 Thread 0x7f29a11e6950 (LWP 13455) 0x00007f29bce76496 in *__GI___poll (fds=0x346a890, nfds=2, timeout=332)
    at ../sysdeps/unix/sysv/linux/poll.c:87
  56 Thread 0x7f29a1bec950 (LWP 13454) pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  55 Thread 0x7f29979b7950 (LWP 13453) pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  4 Thread 0x7f29a39f8950 (LWP 13255) sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
  3 Thread 0x7f29a41f9950 (LWP 13254) 0x00007f29bd9b7c95 in pthread_join (threadid=139816613935440, thread_return=0x0)
    at pthread_join.c:89
  2 Thread 0x7f29b11ae950 (LWP 13252) sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
* 1 Thread 0x7f29bddc26f0 (LWP 13243) sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85

Thread 58 in this case, so let's see where its at:

(gdb) thread 58
[Switching to thread 58 (Thread 0x7f29a2ff0950 (LWP 13456))]#0 0x00007f29ac63e1da in ?? () from /usr/lib/libasound.so.2
(gdb) bt
#0 0x00007f29ac63e1da in ?? () from /usr/lib/libasound.so.2
#1 0x00007f29ac5ff5c1 in ?? () from /usr/lib/libasound.so.2
#2 0x00007f29ac5ff9b7 in ?? () from /usr/lib/libasound.so.2
#3 0x00007f29ac63eb4a in ?? () from /usr/lib/libasound.so.2
#4 0x00007f29ac8c654c in ?? () from /usr/lib/libSDL-1.2.so.0
#5 0x00007f29ac89908e in ?? () from /usr/lib/libSDL-1.2.so.0
#6 0x00007f29ac8a0b77 in ?? () from /usr/lib/libSDL-1.2.so.0
#7 0x00007f29ac8e9e59 in ?? () from /usr/lib/libSDL-1.2.so.0
#8 0x00007f29bd9b73ba in start_thread (arg=<value optimized out>) at pthread_create.c:297
#9 0x00007f29bce7ffcd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10 0x0000000000000000 in ?? ()

So this looks like an audio renderer issue.

As this happens with audio muted too that suggests an additional 'bug': maybe the "mute" side could do with optimising so it doesn't bother rendering muted audio.