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

Phyllis Smith phylsmith2017 at gmail.com
Tue Jan 24 05:24:31 CET 2023


Andrew,
I think it is the same leak.
Leak is gone when I changed the code back.  I will test the one Nikon
d3200.mp4 video I have.
But after that I will have to stop for today due to being too tired.

On Mon, Jan 23, 2023 at 9:16 PM Andrew Randrianasulu <
randrianasulu at gmail.com> wrote:

>
>
> вт, 24 янв. 2023 г., 07:11 Phyllis Smith <phylsmith2017 at gmail.com>:
>
>> Andrew, no - removing that line does not help leak so it must be the "if
>> parent".  It takes awhile to test but will revert from current code of:
>>   if( users == 1 ) {
>>     remove_user();
>>     total_lock->unlock();
>>     return 0
>>   }
>>
>>   //printf("users: %i \n", users );
>>  EDL *parent - edl->parent_edl;
>>  if(parent)
>>    remove_user();
>>
>> To:
>> if( users == 1 ) {
>>     remove_user();
>>     return 0
>>    }
>>    remove_user();
>>
>> Better to have EDL undo problem then run out of memory.
>>
>
>
> hm, may be I'll come with some additional line (like removing this *parent
> link) but can you just comment it out with
>
> // rem: it leask
>
> added?
>
> also, I thought Stefan was chasing earlier leak, may be independent from
> this one
>
>
>>
>>
>>
>> On Mon, Jan 23, 2023 at 8:31 PM Andrew Randrianasulu <
>> randrianasulu at gmail.com> wrote:
>>
>>>
>>>
>>> вт, 24 янв. 2023 г., 06:28 Phyllis Smith <phylsmith2017 at gmail.com>:
>>>
>>>> Andrew, I did get a little confused by part 1 and part 2 of that
>>>> checkin.  Did I get it wrong?
>>>>
>>>
>>>
>>> no ... I hope.
>>>
>>> does removing line I introduced
>>>
>>>          total_lock->unlock();
>>>
>>> help with leak?
>>>
>>>
>>>> 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/980c3dee/attachment-0001.htm>


More information about the Cin mailing list