вс, 22 янв. 2023 г., 21:14 Stefan de Konink <stefan@konink.de>:

Hi Andrew,

Below dooes not give me any significant difference. I have opened 5
viewers, the memory rose from 4GB to 5.2GB, after closing the windows the
memory reduced to 5.1GB.

diff --git a/cinelerra-5.1/cinelerra/vwindow.C
b/cinelerra-5.1/cinelerra/vwindow.C
index 7be15eb8..d477dab1 100644
--- a/cinelerra-5.1/cinelerra/vwindow.C
+++ b/cinelerra-5.1/cinelerra/vwindow.C
@@ -160,6 +160,9 @@ void VWindow::handle_close_event(int result)
{
delete playback_engine;
playback_engine = 0;
+ delete playback_cursor;
+ delete_source(1, 0);
+ delete clip_edit;
}

With the change I have also hit the issue below upon closing the main
application with a viewer open; valgrind is pretty convincing this was
caused by the change. My guess 'delete clip_edit' is at least one of the
issues.

double free or corruption (!prev)

yeah, then it was bad idea (without additional checks at keast)

After reverting the change, I tried some more valgrinding. Cinelerra is
rather slugish with valgrind on, but I have attached, what I see on viewing
some smaller files.

==128034== 3,315,172 (112 direct, 3,315,060 indirect) bytes in 1 blocks are definitely lost in loss record 2,957 of 2,962

==128034== at 0x4843003: operator new(unsigned long) (vg_replace_malloc.c:422)

==128034== by 0x985E79: CICache::check_out(Asset*, EDL*, int) (in /opt/cingg/bin/cin)

==128034== by 0x9304A4: AModule::import_samples(AEdit*, long, long, long, int, int, Samples*, long) (in /opt/cingg/bin/cin)

==128034== by 0x930FCE: AModule::render(Samples*, long, long, int, int, int) (in /opt/cingg/bin/cin)

==128034== by 0xBA389D: VirtualANode::read_data(Samples*, long, long, long) (in /opt/cingg/bin/cin)

==128034== by 0xBA370A: VirtualANode::render_as_module(Samples**, Samples*, long, long, long) (in /opt/cingg/bin/cin)

==128034== by 0xBA375A: VirtualANode::render(Samples*, long, long, long) (in /opt/cingg/bin/cin)

==128034== by 0xBA2442: VirtualAConsole::process_buffer(long, long) (in /opt/cingg/bin/cin)

==128034== by 0x93AA05: ARender::run() (in /opt/cingg/bin/cin)

==128034== by 0xC84DD4: Thread::entrypoint(void*) (in /opt/cingg/bin/cin)

==128034== by 0x67598FC: start_thread (pthread_create.c:442)

==128034== by 0x67DAF33: clone (clone.S:100)

==128034==

==128034== 12,190,657 (480 direct, 12,190,177 indirect) bytes in 1 blocks are definitely lost in loss record 2,961 of 2,962

==128034== at 0x4843003: operator new(unsigned long) (vg_replace_malloc.c:422)

==128034== by 0xA0E107: FFMPEG::open_decoder() (in /opt/cingg/bin/cin)

==128034== by 0xA1928B: FileFFMPEG::open_file(int, int) (in /opt/cingg/bin/cin)

==128034== by 0xA2A933: File::open_file(Preferences*, Asset*, int, int) (in /opt/cingg/bin/cin)

so, something leaks but is it due to mussing free() on exit or also the case for normal operations ... it seems cache is involved, so may be I messed this up somehow. Does leak exist in previous cin-gg, like one from 2021 or 2020?

--
Stefan