[Cin] Complete system hangs (likely out of memory)

[Andrew Randrianasulu]

ср, 25 янв. 2023 г., 04:50 Phyllis Smith via Cin <cin at lists.cinelerra-gg.org
>:

> Problem Solved and some final feedback:
>
> Memory leak fix has been checked into GIT. The problem started Dec. 27 so
> the AppImages created on Dec. 31 will have the problem but not very many
> users update theirs on a monthly basis.
>
> *All *- the Cinelerra program code is really quite complicated so
> problems like this happen.  It will never be bug-free or easy to modify,
> but still we need to attempt changes to move forward.
>
> *Stefan* - thanks so very much for reporting this issue and your
> persistence in working on it.  It is a BIG help when users do their own
> builds because we detect problems earlier that way. Initially my first
> attempt at creating the problem opening new viewers did not create the
> memory leak, apparently because the video contained no audio (so that was a
> bad test on my part). The EDL undo problem does not crash for me, but even
> crashing on other systems is not nice.  To test on the current GIT:
>   1) Load a jpg image, it will expand itself as default 3 sec long
> timeline.
>   2) "Save as" with xml extension.
>   3) Load this xml as nested.
>   4) Hit 'undo' right away.
> For Andrew, it crashes.
>
> *Rob* - you brought up a lot of good questions to investigate which I
> will keep in mind going forward.  Especially something to keep in mind is
> to "transcode your content directly, independently of cinelerra" - this can
> make the input more palatable to Cinelerra.
>
> *Georgy* - after reading your email about "some frames with very special
> properties", I downloaded a video sample and ran "strings" on it (because
> that is about all I knew to do) and certainly found a bunch of weird stuff
> after the initial attributes and before the actual data. And sections
> between as well as on the end.  It must be some kind of filler but it is
> very strange looking (in following, lines were broken up):
>
> ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
> ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
> ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
> ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
> ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
> ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
> ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
> ZZZZZZZZZZZZZZZZZ]
> )iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
> iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
> iiiiiiiiiiiiiiiiiiiiiiiiiiiix!
>
> *Andrew *- I tried again to create the EDL undo crash and still could
> not, but I still have not booted the older distros and 32-bit to check
> them.  I hope to have time tomorrow to  do that and still test the netbsd
> patches from January 12 on those partitions.  Maybe there is a better
> solution to fix the EDL undo crash because the hope is to never crash.
>


well, I think cin* tend to exploit threading in interesting ways, not
obvious even to good programmer, just like it was with bcast2000:

http://mstation.org/bcast.html

=====
Threading offloaded all the concurrency requirements to the operating
system, saving another chunk of coding time. Every window is a separate
thread. Almost every object is a thread. It fills up your process table,
not as elegant as classical signal handling, but it's fast to write.

=====

nested edl a bit never feature exploiting same infrastructure. SO, yes, in
hindsight I should be realize earlier my "fix" just prevent object deletion
in most normal cases, I was too high on apparent "yay, FIX" feeling for
checking memory consumption.

My system a bit more weird than just 32-bit, it actually 64-bit kernel with
32 bit userspace, so you probably need to put "/" of 32bit distro somewhere
on your normally 64-bit OS and then chroot into there. Yet, I am afraid
even this might be not enough due to glibc/gcc/patches difference ....




> *BTW*: filename.opts is one feature of CinGG that is underutilized. But
> it is not that well explained in the manual.
>
> https://cinelerra-gg.org/download/CinelerraGG_Manual/Raw_Input_Opts_File_Video_A.html
>
> https://cinelerra-gg.org/download/CinelerraGG_Manual/Speed_up_Ffmpeg_plugin_usag.html
>
> On Sun, Jan 22, 2023 at 7:54 AM Stefan de Konink via Cin <
> cin at lists.cinelerra-gg.org> wrote:
>
>> Hi,
>>
>> When editing with Cinelerra (current git) I experience frequently that my
>> entire system hangs after scratching through either the timeline or the
>> viewer. As experienced before I have noticed that Cinerella eats a lot of
>> memory.
>>
>> The total amount of assets I have currently in my project is about 70GB,
>> my
>> system memory is 16GB, and yesterday I have added 8GB of swap (normally
>> no
>> swap).
>>
>> It seems that with every video that I preview my memory usage
>> significantly
>> increases, but is never released. I think we have discussed this behavior
>> on the mailinglist before being that the indices never get released. But
>> still the amount does not make sense to me.
>>
>> As user my expectation would be that when I would close the *viewer*, the
>> memory would get released, especially when the content is not placed on
>> the
>> timeline.
>>
>> Are there any statistics available on the memory usage what goes where?
>>
>> Practical question: is it possible to have a different path for the
>> emergency backups than /tmp?
>>
>> --
>> Stefan
>> --
>> Cin mailing list
>> Cin at lists.cinelerra-gg.org
>> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>>
> --
> Cin mailing list
> Cin at lists.cinelerra-gg.org
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20230125/ecfef68f/attachment.htm>