вт, 24 янв. 2023 г., 07:24 Phyllis Smith <[email protected]>:
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 < [email protected]> wrote:
вт, 24 янв. 2023 г., 07:11 Phyllis Smith <[email protected]>:
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 < [email protected]> wrote:
вт, 24 янв. 2023 г., 06:28 Phyllis Smith <[email protected]>:
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 <[email protected]> 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 < [email protected]> wrote:
> > > вт, 24 янв. 2023 г., 02:44 Stefan de Konink <[email protected]>: > >> 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=cinel... > > > 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 >> >