On Tue, May 13, 2014 at 1:04 AM, Janne Liljeblad
<janne.liljeb...@gmail.com>wrote:
> Hi,
>
> After changing trimming code I now have reproducible crash on current
> repository Flowblade. I'm using environment "20140416" as created by
> "build-flowblade.sh".
>
> 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
> consumer.release_modify_lock()
>
> 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.
--
+-DRD-+
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
