[FFmpeg-trac] #4989(undetermined:new): avfilter_graph_create_filter() eventually hits pthread::EAGAIN on multi-threading

[FFmpeg]

#4989: avfilter_graph_create_filter() eventually hits pthread::EAGAIN on multi-
threading
-------------------------------------+-------------------------------------
             Reporter:  czhang384    |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:
  undetermined                       |  unspecified
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 I was trying to convert OPUS to PCM format for my project. And I modified
 transcoding.c example from the source.

 I did use one other library as well but chances for its memory problems
 are really low, so I am guessing some APIs in transcoding.c example may
 cause memory problem?

 There was no specific way to reproduce my problem: my program uses ffmpeg
 to transcode one file, and then passes trancoded file/packet to the other
 library.

 I create an infinite loop to test its limit, and it ranges 300~1500 loops
 of reading one single file (every loop will have 2 ffmpeg to read the same
 file). But the error is consistent: [AVFilterGraph @ 0x12171640] Error
 initializing threading. I check with source code, and it gives
 pthread::EAGAIN, which means the pthread hits the limit.

 Here are some of my investigations so far:
 1. avfilter_graph_create_filter() will call thread_init_internal()
 internally, and then it creats 25 pthreads each. This means I need to
 limit # of threads. I use 4 threads, every thread uses 2 ffmpeg to loop
 the file, so it is 25*4*3 = 200 threads. Given original 4 threads, it
 expects [4, 204] active threads at any time. I tested it, and it number
 was correct.
 2. I checked memory with valgrind: by running 1-5 thread and loops few
 times. The consistent memory problem is "40 bytes still reachable". From
 my research, it is ffmpeg ticket: https://trac.ffmpeg.org/ticket/3194,
 where one internal mutex lock is not freed and occupies that 40 bytes
 memory.
 3. I run only 1 thread. And so far it has been loop ~1900 times and looks
 alright.

  So I am wandering whether any APIs in trancoding.c may allocate some
 secret memory in multi-threading. If not, I guess I can check other non-
 ffmpeg-related sections on it.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/4989>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker