birtwistle:~/csound6> grep -i leak Engine/*.c
Engine/csound_orc_optimize.c:            //Memory leak!!
Engine/csound_orc_optimize.c:            //Memory leak!!
Engine/csound_orc_optimize.c:            //Memory leak!!
Engine/csound_orc_optimize.c:            //Memory leak!!
Engine/cs_par_orc_semantic_analysis.c:    name = cs_strdup(csound, name); // JPff:  leaks: necessary??
Engine/insert.c:    /* that would otherwise result in a memory leak */
Engine/rdscor.c:          memcpy(e->strarg, csound->sstrbuf, csound->sstrlen); /* leaks memory */
birtwistle:~/csound6> 

Hi John,

I'm a bit behind on some emails and wanted to ask if these were all
still things to look at?

Thanks!
steven

On Thu, Oct 26, 2017 at 10:29 AM, jpff  wrote:
> birtwistle:~/csound6> grep -i leak Engine/*.c
> Engine/csound_orc_optimize.c:            //Memory leak!!
> Engine/csound_orc_optimize.c:            //Memory leak!!
> Engine/csound_orc_optimize.c:            //Memory leak!!
> Engine/csound_orc_optimize.c:            //Memory leak!!
> Engine/cs_par_orc_semantic_analysis.c:    name = cs_strdup(csound, name); // JPff:  leaks: necessary??
> Engine/insert.c:    /* that would otherwise result in a memory leak */
> Engine/rdscor.c:          memcpy(e->strarg, csound->sstrbuf, csound->sstrlen); /* leaks memory */
> birtwistle:~/csound6>
>
>

I have got further.  One of the potential leaks is actually OK

But there s one in score reading, first seen in tests/soak/alwayson.csd but 
seems to be any string in a i statement in the score, as used in named 
instruments.  It loses the string as  far as I can tell.  Am investigating 
but not sure I understand the code yet -- in Engine/sread.c

And an update.

The leak in rdscor is fixed.  Uncovered another score related one -- 
running the alwayson example I lost 208 bytes

==856== 64 bytes in 6 blocks are indirectly lost in loss record 63 of 101
==856==    at 0x4C29780: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==856==    by 0x164BA395: ???
==856==    by 0x164B5CDE: ???
==856==    by 0x164AE242: ???
==856==    by 0x164A65F8: ???
==856==    by 0x164A078F: ???
==856==    by 0x1649B7FE: ???
==856==    by 0x164A3824: ???
==856==    by 0x4E91B88: insert (insert.c:300)
==856==    by 0x4E96645: process_score_event (musmon.c:777)
==856==    by 0x4E971DA: process_rt_event (musmon.c:872)
==856==    by 0x4E99038: sensevents (musmon.c:1061)

==856== 208 (144 direct, 64 indirect) bytes in 6 blocks are definitely 
lost in loss record 80 of 101
==856==    at 0x4C29780: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==856==    by 0x1649B3FB: ???
==856==    by 0x164A3824: ???
==856==    by 0x4E91B88: insert (insert.c:300)
==856==    by 0x4E96645: process_score_event (musmon.c:777)
==856==    by 0x4E971DA: process_rt_event (musmon.c:872)
==856==    by 0x4E99038: sensevents (musmon.c:1061)
==856==    by 0x4E7AA61: csoundPerform (csound.c:2147)
==856==    by 0x40155E: main (csound_main.c:324)
==856==



Not sure I have time tonight to tackle these tonight
Line 300 of insert.c is the init calls for the inserted instrment.  So 
suspicio points to an init operation for a opcode or two; possibly connect 
or alwayson?

Te line "operator new..." suggests C++ to me, and te two opcodes are in 
Opcodes/signalflowgraph.cpp