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@gmail.com> wrote:
вт, 24 янв. 2023 г., 07:11 Phyllis Smith <phylsmith2017@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@gmail.com> wrote:
вт, 24 янв. 2023 г., 06:28 Phyllis Smith <phylsmith2017@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@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@gmail.com> wrote:
вт, 24 янв. 2023 г., 02:44 Stefan de Konink <stefan@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=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 >