Comment 3 for bug 403154

Wow! This test with the system monitor has woken me up from my tired
state.

The video files are all on a "projects" partition on one of my internal
harddrives (SATA2). I ran the subsequent tests with only OpenShot,
System Monitor, and Evolution running.

I monitored first: The clip freezing in the viewport, but leaving
Openshot still working in all other respects.

Prior to this viewport freeze, all processors had their loads reasonably
evenly spread with activity in the middle ranges for all of them.

When the viewport froze, one processor went up to 100% and just stayed
there like it was in a never ending loop. The other two processors went
down to a low level of load around 10% or lower. Any activity like
moving the timeline curser or opening a dialogue window caused the two
low level processors to increase their activity a little.

The only thing I found which changed this situation was to open a
file-selection dialogue for importing a clip. This caused the 100%
processor to swap with one of the other processors, so that a different
processor was stuck at 100%, and the original high load processor was
now one of the pair of low load processors!

Second test: Openshot freezing completely on opening the project I sent
you. This did the same thing and caused one processor (#2) to go to
100%, and the other two (#1 & #3) to go to very low load.

I couldn't use the Openshot file-selection dialogue, so I opened gedit.
no activity on that or on the terminal window affected the state of this
#2 100% processor, except opening the file dialogue on gedit caused #2
to go low level, and #1 to switch to 100%! I tried this a few times and
it always caused a different processor to go to 100%. After leaving one
processor running for a few minutes at 100%, the opening of a
file-selection dialogue didn't switch the processors any more. Leaving
that processor permanently at 100%

On killing OpenShot with a "Force Quit", the 100% processor immediately
dropped down to low level and joined the other two so I had then all
three processors in a balanced load at low level.

Therefore I would surmise that freezing of the viewport or the whole of
OpenShot both are caused by a never ending loop as some process is
waiting for a result from a sub process which has probably died, and the
waiting is not being timed out.

Women's intuition suggests to me either: that one of the MLT functions
has a bug where it fails to return an error code when failing. Or else
some function in the Python code is failing to test for the error return
from a function, and is just looping and calling until it gets what it
considers to be a valid return value (which never comes)

 A clue to where this might be is that any call to the Gnome
file-selection dialogue, causes that looping process to be re-spawned on
a different processor. (Wow! This takes me back nearly 20 years to when
I was learning to program Transputer arrays in the Occam2 language!)

At soem point in all of this, some process related to the file selection
is timing out but leaving the looping process as an orphan and so then
it never switches until the application is killed and all related
processes are sent the kill signal. Therefore the orphan process is
still open to signals like KILL. (sig something, I can't remember all
the signal codes anymore)

I hope this helps.

Helen

On Thu, 2009-07-23 at 21:11 +0000, Jonathan Thomas wrote:
> Helen, are your media files located on your primary harddrive? or an
> external harddrive? Also, please check your "System Monitor", and see
> what the CPU is doing while OpenShot is hanging. And, as a side note,
> see how many "Python" processes are running on your computer. There
> should only be a few. Thanks!
>