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

Phyllis Smith phylsmith2017 at gmail.com
Tue Jan 24 04:27:49 CET 2023


Andrew, I did get a little confused by part 1 and part 2 of that checkin.
Did I get it wrong?

On Mon, Jan 23, 2023 at 8:26 PM Phyllis Smith <phylsmith2017 at gmail.com>
wrote:

> Andrew,
> I found where the problem was introduced.
> Dec. 6, 2022 GIT is good.   3c7c8a08800c3e100388996f0e2c2eea9761ebe1
> Dec.27, 2022 GIT is bad.    175a7314e8e927128787feeb7ba5f42530f0a319
>
>
> On Mon, Jan 23, 2023 at 7:51 PM Andrew Randrianasulu <
> randrianasulu at gmail.com> wrote:
>
>>
>>
>> вт, 24 янв. 2023 г., 02:44 Stefan de Konink <stefan at konink.de>:
>>
>>> Hi Andrew,
>>>
>>> When changing this, to be more in line with the "HV" code...
>>>
>>> diff --git a/cinelerra-5.1/cinelerra/playbackengine.C
>>> b/cinelerra-5.1/cinelerra/playbackengine.C
>>> index 815e506f..3c2a9368 100644
>>> --- a/cinelerra-5.1/cinelerra/playbackengine.C
>>> +++ b/cinelerra-5.1/cinelerra/playbackengine.C
>>> @@ -172,9 +172,9 @@ void PlaybackEngine::create_cache()
>>>  {
>>>         cache_lock->lock("PlaybackEngine::create_cache");
>>>         if( audio_cache )
>>> -               audio_cache->remove_user();
>>> +               delete audio_cache;
>>>         if( video_cache )
>>> -               video_cache->remove_user();
>>> +               delete video_cache;
>>>         audio_cache = new CICache(preferences);
>>>         video_cache = new CICache(preferences);
>>>         cache_lock->unlock();
>>>
>>>
>>> ...will result in a fix for the memory leak, but does cause a warning
>>> message.
>>>
>>> Garbage::~Garbage: title=CICache users=1 was not deleted by
>>> Garbage::remove_user
>>>
>>>
>>> This was changed with f5725c7e (7/4/20).
>>
>>
>>
>> https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blobdiff;f=cinelerra-5.1/cinelerra/playbackengine.C;h=82bd7bb6587b930b77caa7f4da7673255539b3a3;hp=8ce98234c3ffc7ed2b0ed6e4c00b4f6e3fa749ee;hb=f5725c7e12def18fec49a295dad688652edaa4b3;hpb=c387b8938dc838e5b92d1cd735975d0928ecf61a
>>
>>
>> hm ....
>>
>> may be you also can try to restore this idea about calling new only if
>> cache does not exist ...
>>
>> @@ -162,10 +164,12 @@ void PlaybackEngine::wait_render_engine()
>>
>>  void PlaybackEngine::create_cache()
>>  {
>> -       if(audio_cache) { delete audio_cache;  audio_cache = 0; }
>> -       if(video_cache) { delete video_cache;  video_cache = 0; }
>> -       if(!audio_cache) audio_cache = new CICache(preferences);
>> -       if(!video_cache) video_cache = new CICache(preferences);
>> +       if( audio_cache )
>> +               audio_cache->remove_user();
>> +       if( video_cache )
>> +               video_cache->remove_user();
>> +       audio_cache = new CICache(preferences);
>> +       video_cache = new CICache(preferences);
>>  }
>>
>>
>>
>>
>> But also shows that many unrelated
>>> changes cause real issues to hide. I found this by hand, not even using
>>> git
>>> bisect. I understand the urge for the garbage collector, but for some
>>> reason not behaving. What I notice is that the 'last' object is empty
>>> when
>>> it is actually destroyed by the garbage collector (~CICache). What is
>>> the
>>> best way going forward?
>>>
>>> --
>>> Stefan
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20230123/a30b8732/attachment.htm>


More information about the Cin mailing list