SIGABRT: thread lock issue in producer_avformat

[sizeofvoid]

Hallo mlt Devs,

first of all thanks for your hard work on MLT. I'm the mlt/kdenlive port maintainer on OpenBSD and some users send me kdenlive backtraces. It's always the same:

#0  thrkill () at -:3
#1  0x0000036f2c98665e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
#2  0x0000036f2c906942 in _libc_pthread_mutex_unlock (mutexp=<optimized out>) at /usr/src/lib/libc/thread/rthread_mutex.c:265
#3  0x0000036f0f9cf372 in producer_set_up_video (self=<optimized out>, frame=0x0) at producer_avformat.c:2329
#4  producer_get_frame (producer=<optimized out>, frame=<optimized out>, index=<optimized out>) at producer_avformat.c:2960
#5  0x0000036f45687d8a in producer_get_frame (service=0x36f37b11400, frame=0x36f1e483860, index=<optimized out>) at mlt_producer.c:647
#6  0x0000036f45686c45 in mlt_service_get_frame (self=0x36f37b11400, frame=0x36f1e483860, index=<optimized out>) at mlt_service.c:593
#7  0x0000036eb9f0cc8c in Mlt::Service::get_frame (this=<optimized out>, index=0) at MltService.cpp:115
#8  0x0000036c7c002d77 in ProjectClip::doExtractImage() ()
#9  0x0000036c7bc89a39 in non-virtual thunk to QtConcurrent::RunFunctionTask<void>::run() ()
#10 0x0000036ee75d5ca7 in QThreadPoolThread::run() () from /usr/local/lib/libQt5Core.so.2.2
#11 0x0000036ee75de820 in QThreadPrivate::start(void*) () from /usr/local/lib/libQt5Core.so.2.2
#12 0x0000036edef087d1 in _rthread_start (v=<optimized out>) at /usr/src/lib/librthread/rthread.c:96
#13 0x0000036f2c97acc8 in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:77
#14 0x0000000000000000 in ?? ()

At first glance ,it looks like a lock problem to me because we run in the abort() call in /usr/src/lib/libc/thread/rthread_mutex.c:

	_rthread_debug(5, "%p: different owner %p (%p)\n", self, (void *)mutex,
	    (void *)mutex->owner);
		if (mutex->type == PTHREAD_MUTEX_ERRORCHECK ||
		    mutex->type == PTHREAD_MUTEX_RECURSIVE) {
			return (EPERM);
		} else {
			/*
			 * For mutex type NORMAL our undefined behavior for
			 * unlocking an unlocked mutex is to succeed without
			 * error.  All other undefined behaviors are to
			 * abort() immediately.
			 */
			if (mutex->owner == NULL &&
			    mutex->type == PTHREAD_MUTEX_NORMAL)
				return (0);
			else
				abort();

		}
	}

I would be happy if we could solve the problem together.

[ddennedy]

@j-b-m if kdenlive is not limiting the number of threads to doExtractImage then it is blowing up the avformat producer cache.

[sizeofvoid]

@j-b-m if kdenlive is not limiting the number of threads to doExtractImage then it is blowing up the avformat producer cache.

Is is a known issue? Under the kdenlive settings there is the default "1" processing thread.

[ddennedy]

Yes, for a long time, and that setting has nothing to do with this. Basically, if your program is going to create an unbound number of threads to extract thumbnails for each file of a multi-file selection, then it is going to blow up unless you set env var MLT_AVFORMAT_PRODUCER_CACHE something very high, but that is going to incur a lot of memory usage.

https://mltframework.org/plugins/ProducerAvformat/#notes