On Tue, May 13, 2014 at 1:04 AM, Janne Liljeblad <janne.liljeblad@gmail.com> wrote:

After changing trimming code I now have reproducible crash on current
repository Flowblade. I'm using environment "20140416" as created by

Steps to reproduce:

1. Add clip to timeline.
2. Cut it into multiple smaller clips.
3. Select trim tool
4. Click on different clips until crash.

Running under "gdb python" seems to always crash immediately after first click.

Doing "bt" in gdb gives always the same trace, which is attached.
"thread apply all bt" is also attached.

It looks like all references on the producer were released while the consumer was still using it. While debugging the other recent crash report from Juan for melted, I had come to believe there is an erroneous release somewhere on a producer (or reference needed but not taken). This is also what I could hypothesize in this bug report https://sourceforge.net/p/mlt/bugs/184/ for which you had a similar one in 190.

This may be the opening to get to those rare crashes that I think
happen because the producer is modified and consumer is reading the
data at the same time. I finally have something reproducible, so maybe
we can fix this.

I'll read the code myself to see if I can come up with some ideas.

I was wondering, if all the threads are in consumer and producers are
only data in memory, we could perhaps do what gtk+ does to prevent
crashes by data manipulation with their gtk.gdk.threads_enter(),
gtk.gdk.threads_leave() pattern.

So it would be something like in application:

// This blocks until all the threads reach point where they can pause to wait,
// probably after rendering a read ahead frame is complete.
consumer.get_modify lock()

// application modifies tractor producer data

//This restarts consumer threads to render next frame

If we could get something like this working it would guarantee that
modifying data does not cause crashes, but maybe there are better ways
to go forward.

You can basically accomplish the same thing today by stopping the consumer, making changes, and then restarting the consumer. Besides, it is not enough to pause the mlt_consumer read-ahead thread. Consumers have their own threads and have frame object references they could be using. Stopping shuts down all threads and flushes remaining frames.

I am in the middle of a heat wave with no air conditioning. So, I have my main workstations turned off and putting off some computer work until the heat reduces later this week.