This is normal looking and not recursive. It is impossible to call mlt_frame_get_image() only once on the stack unless you are making a custom media player. You are not running out of memory on the stack with a call depth of only 53. If you had made a project that includes itself, then it would become recursive and blow out the stack. mlt_pool uses heap memory, and you are out of heap memory. This requires the usual sorts of thing to reduce. Outside of melt reduce other applications. In Kdenlive reduce your resolution, number of tracks, and number of processing thread. Use 64-bit to access more than 3 GiB RAM.
On Mon, Sep 9, 2019 at 3:28 PM Kingsley G. Morse Jr. <kings...@loaner.com> wrote: > Hey guys, > > Thanks again for maintaining melt. > > It's lot of fun! > > I happened to stumble on a use case for version > 6.16.0-4 of debian's package that elicits > > "[mlt_pool] out of memory" > > while rendering edits from version 19.08.0-1 of > debian's kdenlive. > > My commands? > > $ gdb --args melt tmp/bug.2.mlt > > (gdb) b mlt_log if level == 8 > (gdb) r > (gdb) bt > (gdb) bt full > > 2 back traces are attached. > > One lean. > > One full. > > I see repeated calls to mlt_frame.c:620. > > Did you mean to call it recursively? > > (Maybe you could save memory by calling it only > once.) > > Thanks, > Kingsley > > PS: Maybe something like exit.c should be called > after logging "[mlt_pool] out of memory" on > line 161 of mlt_pool.c. > > -- > Time is the fire in which we all burn. > > _______________________________________________ > Mlt-devel mailing list > Mlt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mlt-devel > -- +-DRD-+
_______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
