вт, 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).



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