[Cin] Complete system hangs (likely out of memory)
Andrew Randrianasulu
randrianasulu at gmail.com
Tue Jan 24 06:06:09 CET 2023
вт, 24 янв. 2023 г., 07:24 Phyllis Smith <phylsmith2017 at gmail.com>:
> 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.
>
I tried heaptrack from git and it seems to detect few leaks (over run
cingg, load video, open view from its context menu in resources few times,
quit) , some of them large, as in few megabytes each.
tracking file is 3.6 mb compressed itself
3,6M /home/guest/heaptrack.cin.2457.zst
but processed/compressed by
heaptrack/build/bin/heaptrack_print ~/heap*cin*.zst -l >
~/heaptrack-processed.log
xz -9
is only 8kb. So , attached.
so .... lets sleep over this problem a bit, hopefully we'll find solution
for at least recent regression
> 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/20230124/551ee493/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: heaptrack-processed.log.xz
Type: application/x-xz
Size: 6844 bytes
Desc: not available
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20230124/551ee493/attachment-0001.xz>
More information about the Cin
mailing list