movit library crash when used in kdenlive

When enabling libmovit in kdenlive settings, it always crashes with


Git log from Movit authors:;a=commit;h=2d8043bb837b45c9ae509450b3e1b1eb545e44b9
Unfortunately the change only delays crash from happening, and doesn’t prevent it.
nvidia-bug-report.log.gz (163 KB)

That GL error by itself isn’t very helpful. You need to know what OpenGL call it was trying to make and what its parameters were. However, from the linked commit, it sounds like there’s actually a crash later.

Do you know if there’s a standalone test app that can demonstrate the crash problem?

No, I’m sorry but I don’t know of any, however an appimage of kdenlive (download here: should work. Appimages are standalone sandboxed executables, add execute permissions and launch it like a regular executable. After startup, go to Settings -> Configure Kdenlive -> Playback and make sure “Use GPU processing (Movit library)” is checked. Add a clip to timeline, anything works. After attempting to start playback the application should crash.

Okay, new info. I launched kdenlive in gdb and it’s much more stable. I tried to crash it, but it works just fine.

Thanks. Can you please run and attach the nvidia-bug-report.log.gz file to your post?

personnaly , i think kde should be a part of Mac OS …not on linux

Attached file as requested to the first post.
@Mounir Please refrain yourself from posting those opinions on bug reports, as they have nothing to do with issue at hand.

Thanks kiroma,

I can reproduce a kdenlive crash, but it’s failing an assertion:

kdenlive: resource_pool.cpp:578: GLuint movit::ResourcePool::create_vec2_vao(const std::set<int>&, GLuint): Assertion `vao_formats.count(key) == 0' failed.

As far as I can tell from the code, this just means that it corrupted its own internal tracking list of VAOs.

If you’re in touch with the Movit authors, can you please have them send a more detailed description of the circumstances leading up to the crash and why they believe it is a driver bug to

No, I don’t have any direct contact with them. I can send a mail to the author of the commits, if that helps.
The feature works without any problems on Nouveau drivers, and Intel’s iGPU, therefore so far my suspicions landed on the drivers.
I have some problems with the AppImage though, it might not be as reliable as I thought at first.

P.s. I’m not sure if it’s related, but I managed to crash the app under GDB, and got the following:

Thread 41 "Thread (pooled)" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff577fe700 (LWP 10431)]
0x00007fffe9f0d989 in glDeleteTextures () from /usr/lib/nvidia-384/

did you try this Version 17.03.70 ?

Version of what?

version of kdenlive

I’m compiling kdenlive from source but it’s not even the root of the problem in this thread.
Main problem is with mlt compiled with movit.

Alright, it crashed again with the same output. I might be on to something.
I need to compile entire thing with debugging symbols.
Oh god.

Okay I got the exact same message as aplattner.

Hello, I have also experienced a similar fate with the nvidia propritetary drivers----The same as kiroma here. However I have found that If you build kdenlive from source and mlt with movit enabled(building this also from source) as well as movit from source, it helps alleviate alot of the problem. If you also go into you settings and switch all the “MJPEG” and all the “MPEG” options in KDENLIVE to X264 that helps as well. If you also set a higher number of proxy threads, mlt threads(experimental), and going into project defaults and enabling proxy clips and setting the first video setting to 250pixels as well as the second images to 1000 pixels, and the encoding profile to X264 that also helps alleviate the problem as well… Try also messing with the timeline preview setting as well…In the playback tab I have found that setting the audio backend to SDL and the audio driver to ALSA or PulseAudio.

I havent gotten it fully to work but I have gotten it to work alot more stablly then it was working before…

Just paste this into a file then save to desktop. Open the file from desktop and it should load the settings.
Working Settings for me in the forum on configuration file:


I’m the upstream author of Movit.

I already reported the VAO crash issue to you on July 2nd, but I didn’t receive an answer (thus the workaround). I’ve sent a new mail to now.

Hey Sesse, what would be the workaround for this??? I still get this error even when compiling MLT right from git as well as movit and kdenlive itself… Im trying to work on something important but kdenlive just keeps crashing unstably…

GL error 0x502 (GL_INVALID_OPERATION) at effect_chain.cpp:1987

as well as this when I render the previews on the timeline:

Inconsistency detected by dl-tls.c: 488: _dl_allocate_tls_init: Assertion `listp->slotinfo[cnt].gen <= GL(dl_tls_generation)' failed!

From what I know inconsistencies are created by corrupted libraries, or libraries with broken ABI.

Hey, is there any progress on the issue?

It depends on what you mean by “the issue”. This thread has mentioned three or four distinct issues, which are unlikely to have the same root cause. To try to untangle things:

  • I’ve been working with NVIDIA to reproduce the driver bug affecting Movit’s VAO use that I’ve been mentioning; the effort has been successful, and they’ve fixed the driver bug in question. Given the nature of the bug, however, it is unlikely to have hit Kdenlive. (I’ll let it be up to them if they want to comment in more detail, including when the fix will be released.)
  • Movit 1.5.3 has workarounds for all known VAO bugs, including the previous one, as well as a fix for a crash bug I introduced in Movit 1.5.2.
  • I don’t think anyone has been looking seriously at the remaining reported Kdenlive crashes, assuming they’re not already fixed by using Movit 1.5.3. My personal guess is that GL_INVALID_OPERATION bugs are generally likely to be Kdenlive threading/context issues, but I’m not sure if my guess counts for anything.