I stumbled upon a very bad bug in Kdenlive. This deserves a real bug report. I will do this report, but in the meantime please bear with me while I describe what is going on, just in words. Maybe somebody will immediately spot the problem, just from the description below.

My video project is built in three stages: it includes clips that are kdenlive projects, which in turn include clips that are kdenlive projects. (I have these three stages, because the video production was horribly botched, the two extra stages are here to fix all this: the final project is built from virtual clips that result from correcting the bad original clips.)

Video was shot using three cameras, each with audio, plus a 6-channel (triple stereo) audio recorder. As a result, through most of the project, I have 3 tracks with audio-video clips and 3 stereo audio tracks present. Audio that I do not use is muted, video clips are hiden one by another. This way of working is very convenient to me: I always know what I have available for any point in time. For some fragment of the final video I may use camera 1 with sound from camera 2, but if I later change my mind, it suffices to un-mute one sound, mute another, put one video track on the top of another.

Whenever I need footage from camera 3 (which is usually hidden by clips from cameras 1 and 2), I copy the corresponding clip fragment (e.g. to video track B), possibly timeshift it, possibly add a title. In this case, the fragment from camera 3 in track B hides tracks C, D and E with footage from cameras 1, 2, and 3 (the latter is constantly constantly present in track E). In certain places of the project, you can have, for example, 5 audio-video tracks used:
- track A, a title
- track B below, clip fragment from camera 3 copied here, possibly timeshifted, alpha-blended with the title
- track C below, footage from camera 1 (always present; in this case hidden)
- track D below, footage from camera 2 (always present; in this case hidden)
- track E below, footage from camera 3 (always present; in this case hidden by footage from the same clip, possibly alpha-blended and/or timeshifted)

This project constantly dumps core under kdenlive. When I just edit it with kdenlive, it dumps core very often, but randomly. When I render, MLT dumps core in predictible places (the bug seems easy to reproduce - I promise a real bug report).

I tried various recent versions of kdenlive and MLT. The bug is present everywhere. After some debugging with fprintf and gdb, I found that the coredump is due to a pointer with two very interesting properties:

- the pointer has a very small value (points inside the first, unallocated page), but is non-NULL; this is what causes the coredump
- the pointer changes value (from a value that looks normal to the aforementioned small value) in a mysterious way shortly before the coredump

The two properties make me believe that this is a multithreading bug: some other thread changes the pointer.We have a horribly complicated three-stage project, where the same clip is present in two tracks in the same point of the timeline, and said clip is a kdenlive sub-project, which in turn uses a kdenlive subproject.

My hypothesis is: there is some messs with locking. The way in which threads acquire locks allows two different threads to mess with the same data structure simultaneously. In other words: the way in which data structures describing clips are locked was designed without thinking of the fact that a clip can be an MLT project, which in turn contains an MLT project, and two copies of such a clip can be present on the same point of tghe timeline.

Can somebody in the know shine some light on this hypothesis?

Can somebody in the know suggest me a way of configuring kdenlive/MLT, that will get rid of the problem (force them to use as little threads as possible, maybe effective monothreading is feasible)?

Thank you very much for the tons of attention that this message required from you.

That sounds more like a memory overwrite issue rather than access synchronization.

If you can package up a small test-case that will help greatly.

In the meantime, you might try running Kdenlive under Valgrind. In addition, degugging Kdenlive within an IDE such as KDevelop would help. All you have to do to create a Kdevelop project is open the top-level CMakeLists.txt file.

if this is a multithreading problem in mlt, you can reduce processing threads count down to 1 in Kdenlive settings or in melt command line: does the problem go away like this or is the problem somewhere else?

which pointer is in cause? (can you share full backtrace) ?