Hi All,

Just FYI, Menno reported on the Blue list that there's a problem with
Csound.  WIth the latest from GIT, Blue crashes always after the 3rd
time running Csound (via API).  The email thread has more information
here:

https://sourceforge.net/p/bluemusic/mailman/message/35569588/

I've been able to reproduce the problem here.  Rewinding to commit
2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I can run
Csound multiple times within Blue without problem.

I don't have much more information yet beside that I see that the
crash happens restting Csound.  I'll take a look at using git bisect
to see if I can find the problem.

After running a git bisect session, the commit that was found where
the problem started is this one:

https://github.com/csound/csound/commit/60593c7807cd4d0931254843db2421da6d4dc652

I've pushed a fix at:

https://github.com/csound/csound/commit/a02db25c3d2bc3ab0d89d4f9a6487bf325d8446e

The change seems to make things work as exepcted.  Victor: Could you
review this fix? I think because the values were only freed but not
zeroed, it caused problems on second and third runs and resulted in an
attempt to free a value that was freed before.  However, I'm concerned
about this code being thread-safe, even before my fix.



On Wed, Dec 28, 2016 at 7:29 PM, Steven Yi  wrote:
> Hi All,
>
> Just FYI, Menno reported on the Blue list that there's a problem with
> Csound.  WIth the latest from GIT, Blue crashes always after the 3rd
> time running Csound (via API).  The email thread has more information
> here:
>
> https://sourceforge.net/p/bluemusic/mailman/message/35569588/
>
> I've been able to reproduce the problem here.  Rewinding to commit
> 2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I can run
> Csound multiple times within Blue without problem.
>
> I don't have much more information yet beside that I see that the
> crash happens restting Csound.  I'll take a look at using git bisect
> to see if I can find the problem.
>

This should be ok, since it happens on reset. I had to add those lines because a leak was reported on csoundReset(). 

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 29 Dec 2016, at 02:31, Steven Yi  wrote:
> 
> After running a git bisect session, the commit that was found where
> the problem started is this one:
> 
> https://github.com/csound/csound/commit/60593c7807cd4d0931254843db2421da6d4dc652
> 
> I've pushed a fix at:
> 
> https://github.com/csound/csound/commit/a02db25c3d2bc3ab0d89d4f9a6487bf325d8446e
> 
> The change seems to make things work as exepcted.  Victor: Could you
> review this fix? I think because the values were only freed but not
> zeroed, it caused problems on second and third runs and resulted in an
> attempt to free a value that was freed before.  However, I'm concerned
> about this code being thread-safe, even before my fix.
> 
> 
> 
>> On Wed, Dec 28, 2016 at 7:29 PM, Steven Yi  wrote:
>> Hi All,
>> 
>> Just FYI, Menno reported on the Blue list that there's a problem with
>> Csound.  WIth the latest from GIT, Blue crashes always after the 3rd
>> time running Csound (via API).  The email thread has more information
>> here:
>> 
>> https://sourceforge.net/p/bluemusic/mailman/message/35569588/
>> 
>> I've been able to reproduce the problem here.  Rewinding to commit
>> 2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I can run
>> Csound multiple times within Blue without problem.
>> 
>> I don't have much more information yet beside that I see that the
>> crash happens restting Csound.  I'll take a look at using git bisect
>> to see if I can find the problem.
>> 

Would there be problems if multiple Csound instances are created? (thinking of how Rory uses Csound instances in Cabbage)

Looks as if flowgraph uses data statics which we removed throughout csound 
to make it re-entrant.   So it is unsafe

On Thu, 29 Dec 2016, Steven Yi wrote:

> 
> Would there be problems if multiple Csound instances are created? (thinking of
> how Rory uses Csound instances in Cabbage)
> 
> 
> On Thu, Dec 29, 2016, 5:11 AM Victor Lazzarini 
> wrote:
>       This should be ok, since it happens on reset. I had to add those
>       lines because a leak was reported on csoundReset().
>
>       Victor Lazzarini
>       Dean of Arts, Celtic Studies, and Philosophy
>       Maynooth University
>       Ireland
>
>       > On 29 Dec 2016, at 02:31, Steven Yi  wrote:
>       >
>       > After running a git bisect session, the commit that was found
>       where
>       > the problem started is this one:
>       >
>       >https://github.com/csound/csound/commit/60593c7807cd4d0931254843db2421da6d4dc
>       652
>       >
>       > I've pushed a fix at:
>       >
>       >https://github.com/csound/csound/commit/a02db25c3d2bc3ab0d89d4f9a6487bf325d84
>       46e
>       >
>       > The change seems to make things work as exepcted.  Victor: Could
>       you
>       > review this fix? I think because the values were only freed but
>       not
>       > zeroed, it caused problems on second and third runs and resulted
>       in an
>       > attempt to free a value that was freed before.  However, I'm
>       concerned
>       > about this code being thread-safe, even before my fix.
>       >
>       >
>       >
>       >> On Wed, Dec 28, 2016 at 7:29 PM, Steven Yi 
>       wrote:
>       >> Hi All,
>       >>
>       >> Just FYI, Menno reported on the Blue list that there's a
>       problem with
>       >> Csound.  WIth the latest from GIT, Blue crashes always after
>       the 3rd
>       >> time running Csound (via API).  The email thread has more
>       information
>       >> here:
>       >>
>       >> https://sourceforge.net/p/bluemusic/mailman/message/35569588/
>       >>
>       >> I've been able to reproduce the problem here.  Rewinding to
>       commit
>       >> 2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I
>       can run
>       >> Csound multiple times within Blue without problem.
>       >>
>       >> I don't have much more information yet beside that I see that
>       the
>       >> crash happens restting Csound.  I'll take a look at using git
>       bisect
>       >> to see if I can find the problem.
>       >>
>       >> steven
> 
> 
>

If you are talking about the signal flow graph opcodes, the code is
re-entrant. There are indeed static tables of objects, but those
objects are mapped by Csound instance as well as object instance.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Thu, Dec 29, 2016 at 10:40 AM, jpff  wrote:
> Looks as if flowgraph uses data statics which we removed throughout csound
> to make it re-entrant.   So it is unsafe
>
>
> On Thu, 29 Dec 2016, Steven Yi wrote:
>
>>
>> Would there be problems if multiple Csound instances are created?
>> (thinking of
>> how Rory uses Csound instances in Cabbage)
>>
>>
>> On Thu, Dec 29, 2016, 5:11 AM Victor Lazzarini 
>> wrote:
>>       This should be ok, since it happens on reset. I had to add those
>>       lines because a leak was reported on csoundReset().
>>
>>       Victor Lazzarini
>>       Dean of Arts, Celtic Studies, and Philosophy
>>       Maynooth University
>>       Ireland
>>
>>       > On 29 Dec 2016, at 02:31, Steven Yi  wrote:
>>       >
>>       > After running a git bisect session, the commit that was found
>>       where
>>       > the problem started is this one:
>>       >
>>
>> >https://github.com/csound/csound/commit/60593c7807cd4d0931254843db2421da6d4dc
>>       652
>>       >
>>       > I've pushed a fix at:
>>       >
>>
>> >https://github.com/csound/csound/commit/a02db25c3d2bc3ab0d89d4f9a6487bf325d84
>>       46e
>>       >
>>       > The change seems to make things work as exepcted.  Victor: Could
>>       you
>>       > review this fix? I think because the values were only freed but
>>       not
>>       > zeroed, it caused problems on second and third runs and resulted
>>       in an
>>       > attempt to free a value that was freed before.  However, I'm
>>       concerned
>>       > about this code being thread-safe, even before my fix.
>>       >
>>       >
>>       >
>>       >> On Wed, Dec 28, 2016 at 7:29 PM, Steven Yi 
>>       wrote:
>>       >> Hi All,
>>       >>
>>       >> Just FYI, Menno reported on the Blue list that there's a
>>       problem with
>>       >> Csound.  WIth the latest from GIT, Blue crashes always after
>>       the 3rd
>>       >> time running Csound (via API).  The email thread has more
>>       information
>>       >> here:
>>       >>
>>       >> https://sourceforge.net/p/bluemusic/mailman/message/35569588/
>>       >>
>>       >> I've been able to reproduce the problem here.  Rewinding to
>>       commit
>>       >> 2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I
>>       can run
>>       >> Csound multiple times within Blue without problem.
>>       >>
>>       >> I don't have much more information yet beside that I see that
>>       the
>>       >> crash happens restting Csound.  I'll take a look at using git
>>       bisect
>>       >> to see if I can find the problem.
>>       >>
>>       >> steven
>>
>>

I think John and I are referring to these uses of static mutex locks:

https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L138-L139
https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818



On Thu, Dec 29, 2016 at 11:33 AM, Michael Gogins
 wrote:
> If you are talking about the signal flow graph opcodes, the code is
> re-entrant. There are indeed static tables of objects, but those
> objects are mapped by Csound instance as well as object instance.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Thu, Dec 29, 2016 at 10:40 AM, jpff  wrote:
>> Looks as if flowgraph uses data statics which we removed throughout csound
>> to make it re-entrant.   So it is unsafe
>>
>>
>> On Thu, 29 Dec 2016, Steven Yi wrote:
>>
>>>
>>> Would there be problems if multiple Csound instances are created?
>>> (thinking of
>>> how Rory uses Csound instances in Cabbage)
>>>
>>>
>>> On Thu, Dec 29, 2016, 5:11 AM Victor Lazzarini 
>>> wrote:
>>>       This should be ok, since it happens on reset. I had to add those
>>>       lines because a leak was reported on csoundReset().
>>>
>>>       Victor Lazzarini
>>>       Dean of Arts, Celtic Studies, and Philosophy
>>>       Maynooth University
>>>       Ireland
>>>
>>>       > On 29 Dec 2016, at 02:31, Steven Yi  wrote:
>>>       >
>>>       > After running a git bisect session, the commit that was found
>>>       where
>>>       > the problem started is this one:
>>>       >
>>>
>>> >https://github.com/csound/csound/commit/60593c7807cd4d0931254843db2421da6d4dc
>>>       652
>>>       >
>>>       > I've pushed a fix at:
>>>       >
>>>
>>> >https://github.com/csound/csound/commit/a02db25c3d2bc3ab0d89d4f9a6487bf325d84
>>>       46e
>>>       >
>>>       > The change seems to make things work as exepcted.  Victor: Could
>>>       you
>>>       > review this fix? I think because the values were only freed but
>>>       not
>>>       > zeroed, it caused problems on second and third runs and resulted
>>>       in an
>>>       > attempt to free a value that was freed before.  However, I'm
>>>       concerned
>>>       > about this code being thread-safe, even before my fix.
>>>       >
>>>       >
>>>       >
>>>       >> On Wed, Dec 28, 2016 at 7:29 PM, Steven Yi 
>>>       wrote:
>>>       >> Hi All,
>>>       >>
>>>       >> Just FYI, Menno reported on the Blue list that there's a
>>>       problem with
>>>       >> Csound.  WIth the latest from GIT, Blue crashes always after
>>>       the 3rd
>>>       >> time running Csound (via API).  The email thread has more
>>>       information
>>>       >> here:
>>>       >>
>>>       >> https://sourceforge.net/p/bluemusic/mailman/message/35569588/
>>>       >>
>>>       >> I've been able to reproduce the problem here.  Rewinding to
>>>       commit
>>>       >> 2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I
>>>       can run
>>>       >> Csound multiple times within Blue without problem.
>>>       >>
>>>       >> I don't have much more information yet beside that I see that
>>>       the
>>>       >> crash happens restting Csound.  I'll take a look at using git
>>>       bisect
>>>       >> to see if I can find the problem.
>>>       >>
>>>       >> steven
>>>
>>>

I am looking into statics throughout.  At first glace it seems thee are 
statics in the parser and elsewere.  I am preparing a list

Got it, thanks.

Yes, that's a problem. The mutexes are supposed to protect the data
tables from data races or overwrites between different instances of
Csound, but of course if the module is destroyed by one instance while
being used by another instance, the current code will not work. To
precise, the current code is fine for different instances of Csound
that run in different processes, but if there are different instances
of Csound in the same process, then there is a problem.

The best solution is just to leave these variables alone. Don't try to
delete or zero them. If you think they really need to be deleted, it
should not be done in csoundReset but in an atexit handler. For a
process, they'll just go away when the process exits. For different
instances of Csound in the same process, these mutexes should in fact
be global to the process.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Thu, Dec 29, 2016 at 11:43 AM, Steven Yi  wrote:
> I think John and I are referring to these uses of static mutex locks:
>
> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L138-L139
> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>
>
>
> On Thu, Dec 29, 2016 at 11:33 AM, Michael Gogins
>  wrote:
>> If you are talking about the signal flow graph opcodes, the code is
>> re-entrant. There are indeed static tables of objects, but those
>> objects are mapped by Csound instance as well as object instance.
>>
>> Regards,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Thu, Dec 29, 2016 at 10:40 AM, jpff  wrote:
>>> Looks as if flowgraph uses data statics which we removed throughout csound
>>> to make it re-entrant.   So it is unsafe
>>>
>>>
>>> On Thu, 29 Dec 2016, Steven Yi wrote:
>>>
>>>>
>>>> Would there be problems if multiple Csound instances are created?
>>>> (thinking of
>>>> how Rory uses Csound instances in Cabbage)
>>>>
>>>>
>>>> On Thu, Dec 29, 2016, 5:11 AM Victor Lazzarini 
>>>> wrote:
>>>>       This should be ok, since it happens on reset. I had to add those
>>>>       lines because a leak was reported on csoundReset().
>>>>
>>>>       Victor Lazzarini
>>>>       Dean of Arts, Celtic Studies, and Philosophy
>>>>       Maynooth University
>>>>       Ireland
>>>>
>>>>       > On 29 Dec 2016, at 02:31, Steven Yi  wrote:
>>>>       >
>>>>       > After running a git bisect session, the commit that was found
>>>>       where
>>>>       > the problem started is this one:
>>>>       >
>>>>
>>>> >https://github.com/csound/csound/commit/60593c7807cd4d0931254843db2421da6d4dc
>>>>       652
>>>>       >
>>>>       > I've pushed a fix at:
>>>>       >
>>>>
>>>> >https://github.com/csound/csound/commit/a02db25c3d2bc3ab0d89d4f9a6487bf325d84
>>>>       46e
>>>>       >
>>>>       > The change seems to make things work as exepcted.  Victor: Could
>>>>       you
>>>>       > review this fix? I think because the values were only freed but
>>>>       not
>>>>       > zeroed, it caused problems on second and third runs and resulted
>>>>       in an
>>>>       > attempt to free a value that was freed before.  However, I'm
>>>>       concerned
>>>>       > about this code being thread-safe, even before my fix.
>>>>       >
>>>>       >
>>>>       >
>>>>       >> On Wed, Dec 28, 2016 at 7:29 PM, Steven Yi 
>>>>       wrote:
>>>>       >> Hi All,
>>>>       >>
>>>>       >> Just FYI, Menno reported on the Blue list that there's a
>>>>       problem with
>>>>       >> Csound.  WIth the latest from GIT, Blue crashes always after
>>>>       the 3rd
>>>>       >> time running Csound (via API).  The email thread has more
>>>>       information
>>>>       >> here:
>>>>       >>
>>>>       >> https://sourceforge.net/p/bluemusic/mailman/message/35569588/
>>>>       >>
>>>>       >> I've been able to reproduce the problem here.  Rewinding to
>>>>       commit
>>>>       >> 2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I
>>>>       can run
>>>>       >> Csound multiple times within Blue without problem.
>>>>       >>
>>>>       >> I don't have much more information yet beside that I see that
>>>>       the
>>>>       >> crash happens restting Csound.  I'll take a look at using git
>>>>       bisect
>>>>       >> to see if I can find the problem.
>>>>       >>
>>>>       >> steven
>>>>
>>>>

Just to be crystal clear about this...

Static variables should be avoided if at all possible, but in some
cases they may be necessary in order to share data between instances
of Csound that run in the same process. In such cases, the variables
should be created and initialized only once in the process no matter
how many instances of Csound there are in that process, and deleted
only at exit.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Thu, Dec 29, 2016 at 12:03 PM, Michael Gogins
 wrote:
> Got it, thanks.
>
> Yes, that's a problem. The mutexes are supposed to protect the data
> tables from data races or overwrites between different instances of
> Csound, but of course if the module is destroyed by one instance while
> being used by another instance, the current code will not work. To
> precise, the current code is fine for different instances of Csound
> that run in different processes, but if there are different instances
> of Csound in the same process, then there is a problem.
>
> The best solution is just to leave these variables alone. Don't try to
> delete or zero them. If you think they really need to be deleted, it
> should not be done in csoundReset but in an atexit handler. For a
> process, they'll just go away when the process exits. For different
> instances of Csound in the same process, these mutexes should in fact
> be global to the process.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Thu, Dec 29, 2016 at 11:43 AM, Steven Yi  wrote:
>> I think John and I are referring to these uses of static mutex locks:
>>
>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L138-L139
>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>
>>
>>
>> On Thu, Dec 29, 2016 at 11:33 AM, Michael Gogins
>>  wrote:
>>> If you are talking about the signal flow graph opcodes, the code is
>>> re-entrant. There are indeed static tables of objects, but those
>>> objects are mapped by Csound instance as well as object instance.
>>>
>>> Regards,
>>> Mike
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Thu, Dec 29, 2016 at 10:40 AM, jpff  wrote:
>>>> Looks as if flowgraph uses data statics which we removed throughout csound
>>>> to make it re-entrant.   So it is unsafe
>>>>
>>>>
>>>> On Thu, 29 Dec 2016, Steven Yi wrote:
>>>>
>>>>>
>>>>> Would there be problems if multiple Csound instances are created?
>>>>> (thinking of
>>>>> how Rory uses Csound instances in Cabbage)
>>>>>
>>>>>
>>>>> On Thu, Dec 29, 2016, 5:11 AM Victor Lazzarini 
>>>>> wrote:
>>>>>       This should be ok, since it happens on reset. I had to add those
>>>>>       lines because a leak was reported on csoundReset().
>>>>>
>>>>>       Victor Lazzarini
>>>>>       Dean of Arts, Celtic Studies, and Philosophy
>>>>>       Maynooth University
>>>>>       Ireland
>>>>>
>>>>>       > On 29 Dec 2016, at 02:31, Steven Yi  wrote:
>>>>>       >
>>>>>       > After running a git bisect session, the commit that was found
>>>>>       where
>>>>>       > the problem started is this one:
>>>>>       >
>>>>>
>>>>> >https://github.com/csound/csound/commit/60593c7807cd4d0931254843db2421da6d4dc
>>>>>       652
>>>>>       >
>>>>>       > I've pushed a fix at:
>>>>>       >
>>>>>
>>>>> >https://github.com/csound/csound/commit/a02db25c3d2bc3ab0d89d4f9a6487bf325d84
>>>>>       46e
>>>>>       >
>>>>>       > The change seems to make things work as exepcted.  Victor: Could
>>>>>       you
>>>>>       > review this fix? I think because the values were only freed but
>>>>>       not
>>>>>       > zeroed, it caused problems on second and third runs and resulted
>>>>>       in an
>>>>>       > attempt to free a value that was freed before.  However, I'm
>>>>>       concerned
>>>>>       > about this code being thread-safe, even before my fix.
>>>>>       >
>>>>>       >
>>>>>       >
>>>>>       >> On Wed, Dec 28, 2016 at 7:29 PM, Steven Yi 
>>>>>       wrote:
>>>>>       >> Hi All,
>>>>>       >>
>>>>>       >> Just FYI, Menno reported on the Blue list that there's a
>>>>>       problem with
>>>>>       >> Csound.  WIth the latest from GIT, Blue crashes always after
>>>>>       the 3rd
>>>>>       >> time running Csound (via API).  The email thread has more
>>>>>       information
>>>>>       >> here:
>>>>>       >>
>>>>>       >> https://sourceforge.net/p/bluemusic/mailman/message/35569588/
>>>>>       >>
>>>>>       >> I've been able to reproduce the problem here.  Rewinding to
>>>>>       commit
>>>>>       >> 2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I
>>>>>       can run
>>>>>       >> Csound multiple times within Blue without problem.
>>>>>       >>
>>>>>       >> I don't have much more information yet beside that I see that
>>>>>       the
>>>>>       >> crash happens restting Csound.  I'll take a look at using git
>>>>>       bisect
>>>>>       >> to see if I can find the problem.
>>>>>       >>
>>>>>       >> steven
>>>>>
>>>>>

I am not aware of problems with that, but it might be worth checking. That fix was in response to
this issue

https://github.com/csound/csound/issues/722
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 29 Dec 2016, at 14:31, Steven Yi  wrote:
> 
> Would there be problems if multiple Csound instances are created? (thinking of how Rory uses Csound instances in Cabbage)
> 
> 
> On Thu, Dec 29, 2016, 5:11 AM Victor Lazzarini  wrote:
> This should be ok, since it happens on reset. I had to add those lines because a leak was reported on csoundReset().
> 
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
> 
> > On 29 Dec 2016, at 02:31, Steven Yi  wrote:
> >
> > After running a git bisect session, the commit that was found where
> > the problem started is this one:
> >
> > https://github.com/csound/csound/commit/60593c7807cd4d0931254843db2421da6d4dc652
> >
> > I've pushed a fix at:
> >
> > https://github.com/csound/csound/commit/a02db25c3d2bc3ab0d89d4f9a6487bf325d8446e
> >
> > The change seems to make things work as exepcted.  Victor: Could you
> > review this fix? I think because the values were only freed but not
> > zeroed, it caused problems on second and third runs and resulted in an
> > attempt to free a value that was freed before.  However, I'm concerned
> > about this code being thread-safe, even before my fix.
> >
> >
> >
> >> On Wed, Dec 28, 2016 at 7:29 PM, Steven Yi  wrote:
> >> Hi All,
> >>
> >> Just FYI, Menno reported on the Blue list that there's a problem with
> >> Csound.  WIth the latest from GIT, Blue crashes always after the 3rd
> >> time running Csound (via API).  The email thread has more information
> >> here:
> >>
> >> https://sourceforge.net/p/bluemusic/mailman/message/35569588/
> >>
> >> I've been able to reproduce the problem here.  Rewinding to commit
> >> 2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I can run
> >> Csound multiple times within Blue without problem.
> >>
> >> I don't have much more information yet beside that I see that the
> >> crash happens restting Csound.  I'll take a look at using git bisect
> >> to see if I can find the problem.
> >>

They needed to be cleared because they were causing memory leaks every time
Csound is reset. I chased all of these leaks and there are none now (at least on OSX/Linux).

https://github.com/csound/csound/issues/722

Even if we are not using the opcodes, the loading and unloading process will leak memory.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 29 Dec 2016, at 17:03, Michael Gogins  wrote:
> 
> Got it, thanks.
> 
> Yes, that's a problem. The mutexes are supposed to protect the data
> tables from data races or overwrites between different instances of
> Csound, but of course if the module is destroyed by one instance while
> being used by another instance, the current code will not work. To
> precise, the current code is fine for different instances of Csound
> that run in different processes, but if there are different instances
> of Csound in the same process, then there is a problem.
> 
> The best solution is just to leave these variables alone. Don't try to
> delete or zero them. If you think they really need to be deleted, it
> should not be done in csoundReset but in an atexit handler. For a
> process, they'll just go away when the process exits. For different
> instances of Csound in the same process, these mutexes should in fact
> be global to the process.
> 
> Regards,
> Mike
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
> 
> 
> On Thu, Dec 29, 2016 at 11:43 AM, Steven Yi  wrote:
>> I think John and I are referring to these uses of static mutex locks:
>> 
>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L138-L139
>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>> 
>> 
>> 
>> On Thu, Dec 29, 2016 at 11:33 AM, Michael Gogins
>>  wrote:
>>> If you are talking about the signal flow graph opcodes, the code is
>>> re-entrant. There are indeed static tables of objects, but those
>>> objects are mapped by Csound instance as well as object instance.
>>> 
>>> Regards,
>>> Mike
>>> 
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>> 
>>> 
>>> On Thu, Dec 29, 2016 at 10:40 AM, jpff  wrote:
>>>> Looks as if flowgraph uses data statics which we removed throughout csound
>>>> to make it re-entrant.   So it is unsafe
>>>> 
>>>> 
>>>> On Thu, 29 Dec 2016, Steven Yi wrote:
>>>> 
>>>>> 
>>>>> Would there be problems if multiple Csound instances are created?
>>>>> (thinking of
>>>>> how Rory uses Csound instances in Cabbage)
>>>>> 
>>>>> 
>>>>> On Thu, Dec 29, 2016, 5:11 AM Victor Lazzarini 
>>>>> wrote:
>>>>>      This should be ok, since it happens on reset. I had to add those
>>>>>      lines because a leak was reported on csoundReset().
>>>>> 
>>>>>      Victor Lazzarini
>>>>>      Dean of Arts, Celtic Studies, and Philosophy
>>>>>      Maynooth University
>>>>>      Ireland
>>>>> 
>>>>>> On 29 Dec 2016, at 02:31, Steven Yi  wrote:
>>>>>> 
>>>>>> After running a git bisect session, the commit that was found
>>>>>      where
>>>>>> the problem started is this one:
>>>>>> 
>>>>> 
>>>>>> https://github.com/csound/csound/commit/60593c7807cd4d0931254843db2421da6d4dc
>>>>>      652
>>>>>> 
>>>>>> I've pushed a fix at:
>>>>>> 
>>>>> 
>>>>>> https://github.com/csound/csound/commit/a02db25c3d2bc3ab0d89d4f9a6487bf325d84
>>>>>      46e
>>>>>> 
>>>>>> The change seems to make things work as exepcted.  Victor: Could
>>>>>      you
>>>>>> review this fix? I think because the values were only freed but
>>>>>      not
>>>>>> zeroed, it caused problems on second and third runs and resulted
>>>>>      in an
>>>>>> attempt to free a value that was freed before.  However, I'm
>>>>>      concerned
>>>>>> about this code being thread-safe, even before my fix.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Wed, Dec 28, 2016 at 7:29 PM, Steven Yi 
>>>>>      wrote:
>>>>>>> Hi All,
>>>>>>> 
>>>>>>> Just FYI, Menno reported on the Blue list that there's a
>>>>>      problem with
>>>>>>> Csound.  WIth the latest from GIT, Blue crashes always after
>>>>>      the 3rd
>>>>>>> time running Csound (via API).  The email thread has more
>>>>>      information
>>>>>>> here:
>>>>>>> 
>>>>>>> https://sourceforge.net/p/bluemusic/mailman/message/35569588/
>>>>>>> 
>>>>>>> I've been able to reproduce the problem here.  Rewinding to
>>>>>      commit
>>>>>>> 2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I
>>>>>      can run
>>>>>>> Csound multiple times within Blue without problem.
>>>>>>> 
>>>>>>> I don't have much more information yet beside that I see that
>>>>>      the
>>>>>>> crash happens restting Csound.  I'll take a look at using git
>>>>>      bisect
>>>>>>> to see if I can find the problem.
>>>>>>> 
>>>>>>> steven
>>>>> 
>>>>> 

I understand about the memory leak, but my view was that this is an
acceptable tradeoff: Either there is a small memory leak but multiple
instances of Csound can run in the same process using the signal
flowgraph opcodes, as with Cabbage plugins or CsoundVST in a digital
audio workstation, or the signal flow graph opcodes cannot be used in
a DAW but there is no memory leak from these mutexes.

However, a better option is to use an atexit handler for these global
statics. At any rate, I will debug this and find out what is really
going on.

The scale of memory growth reported in issue 722 is vastly greater
than that reported by valgrind. Does anybody have an answer for that?
Does it occur only with soundfile output or only for real-time audio
output?

In issue 722,do you mean the jack driver for command-line options, or
the Jacko opcodes?

Regards,
Mike


-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Thu, Dec 29, 2016 at 12:45 PM, Victor Lazzarini
 wrote:
> They needed to be cleared because they were causing memory leaks every time
> Csound is reset. I chased all of these leaks and there are none now (at least on OSX/Linux).
>
> https://github.com/csound/csound/issues/722
>
> Even if we are not using the opcodes, the loading and unloading process will leak memory.
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
>> On 29 Dec 2016, at 17:03, Michael Gogins  wrote:
>>
>> Got it, thanks.
>>
>> Yes, that's a problem. The mutexes are supposed to protect the data
>> tables from data races or overwrites between different instances of
>> Csound, but of course if the module is destroyed by one instance while
>> being used by another instance, the current code will not work. To
>> precise, the current code is fine for different instances of Csound
>> that run in different processes, but if there are different instances
>> of Csound in the same process, then there is a problem.
>>
>> The best solution is just to leave these variables alone. Don't try to
>> delete or zero them. If you think they really need to be deleted, it
>> should not be done in csoundReset but in an atexit handler. For a
>> process, they'll just go away when the process exits. For different
>> instances of Csound in the same process, these mutexes should in fact
>> be global to the process.
>>
>> Regards,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Thu, Dec 29, 2016 at 11:43 AM, Steven Yi  wrote:
>>> I think John and I are referring to these uses of static mutex locks:
>>>
>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L138-L139
>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>>
>>>
>>>
>>> On Thu, Dec 29, 2016 at 11:33 AM, Michael Gogins
>>>  wrote:
>>>> If you are talking about the signal flow graph opcodes, the code is
>>>> re-entrant. There are indeed static tables of objects, but those
>>>> objects are mapped by Csound instance as well as object instance.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> -----------------------------------------------------
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://michaelgogins.tumblr.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>>
>>>> On Thu, Dec 29, 2016 at 10:40 AM, jpff  wrote:
>>>>> Looks as if flowgraph uses data statics which we removed throughout csound
>>>>> to make it re-entrant.   So it is unsafe
>>>>>
>>>>>
>>>>> On Thu, 29 Dec 2016, Steven Yi wrote:
>>>>>
>>>>>>
>>>>>> Would there be problems if multiple Csound instances are created?
>>>>>> (thinking of
>>>>>> how Rory uses Csound instances in Cabbage)
>>>>>>
>>>>>>
>>>>>> On Thu, Dec 29, 2016, 5:11 AM Victor Lazzarini 
>>>>>> wrote:
>>>>>>      This should be ok, since it happens on reset. I had to add those
>>>>>>      lines because a leak was reported on csoundReset().
>>>>>>
>>>>>>      Victor Lazzarini
>>>>>>      Dean of Arts, Celtic Studies, and Philosophy
>>>>>>      Maynooth University
>>>>>>      Ireland
>>>>>>
>>>>>>> On 29 Dec 2016, at 02:31, Steven Yi  wrote:
>>>>>>>
>>>>>>> After running a git bisect session, the commit that was found
>>>>>>      where
>>>>>>> the problem started is this one:
>>>>>>>
>>>>>>
>>>>>>> https://github.com/csound/csound/commit/60593c7807cd4d0931254843db2421da6d4dc
>>>>>>      652
>>>>>>>
>>>>>>> I've pushed a fix at:
>>>>>>>
>>>>>>
>>>>>>> https://github.com/csound/csound/commit/a02db25c3d2bc3ab0d89d4f9a6487bf325d84
>>>>>>      46e
>>>>>>>
>>>>>>> The change seems to make things work as exepcted.  Victor: Could
>>>>>>      you
>>>>>>> review this fix? I think because the values were only freed but
>>>>>>      not
>>>>>>> zeroed, it caused problems on second and third runs and resulted
>>>>>>      in an
>>>>>>> attempt to free a value that was freed before.  However, I'm
>>>>>>      concerned
>>>>>>> about this code being thread-safe, even before my fix.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Wed, Dec 28, 2016 at 7:29 PM, Steven Yi 
>>>>>>      wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Just FYI, Menno reported on the Blue list that there's a
>>>>>>      problem with
>>>>>>>> Csound.  WIth the latest from GIT, Blue crashes always after
>>>>>>      the 3rd
>>>>>>>> time running Csound (via API).  The email thread has more
>>>>>>      information
>>>>>>>> here:
>>>>>>>>
>>>>>>>> https://sourceforge.net/p/bluemusic/mailman/message/35569588/
>>>>>>>>
>>>>>>>> I've been able to reproduce the problem here.  Rewinding to
>>>>>>      commit
>>>>>>>> 2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I
>>>>>>      can run
>>>>>>>> Csound multiple times within Blue without problem.
>>>>>>>>
>>>>>>>> I don't have much more information yet beside that I see that
>>>>>>      the
>>>>>>>> crash happens restting Csound.  I'll take a look at using git
>>>>>>      bisect
>>>>>>>> to see if I can find the problem.
>>>>>>>>
>>>>>>>> steven
>>>>>>
>>>>>>

Please look at the code I changed.  It should address the issue of
freeing memory but also having things be re-entrant.  Menno and I have
been looking at this and he's now running multiple runs from Blue
without problems, a have I.

On Thu, Dec 29, 2016 at 3:12 PM, Michael Gogins
 wrote:
> I understand about the memory leak, but my view was that this is an
> acceptable tradeoff: Either there is a small memory leak but multiple
> instances of Csound can run in the same process using the signal
> flowgraph opcodes, as with Cabbage plugins or CsoundVST in a digital
> audio workstation, or the signal flow graph opcodes cannot be used in
> a DAW but there is no memory leak from these mutexes.
>
> However, a better option is to use an atexit handler for these global
> statics. At any rate, I will debug this and find out what is really
> going on.
>
> The scale of memory growth reported in issue 722 is vastly greater
> than that reported by valgrind. Does anybody have an answer for that?
> Does it occur only with soundfile output or only for real-time audio
> output?
>
> In issue 722,do you mean the jack driver for command-line options, or
> the Jacko opcodes?
>
> Regards,
> Mike
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Thu, Dec 29, 2016 at 12:45 PM, Victor Lazzarini
>  wrote:
>> They needed to be cleared because they were causing memory leaks every time
>> Csound is reset. I chased all of these leaks and there are none now (at least on OSX/Linux).
>>
>> https://github.com/csound/csound/issues/722
>>
>> Even if we are not using the opcodes, the loading and unloading process will leak memory.
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>>
>>> On 29 Dec 2016, at 17:03, Michael Gogins  wrote:
>>>
>>> Got it, thanks.
>>>
>>> Yes, that's a problem. The mutexes are supposed to protect the data
>>> tables from data races or overwrites between different instances of
>>> Csound, but of course if the module is destroyed by one instance while
>>> being used by another instance, the current code will not work. To
>>> precise, the current code is fine for different instances of Csound
>>> that run in different processes, but if there are different instances
>>> of Csound in the same process, then there is a problem.
>>>
>>> The best solution is just to leave these variables alone. Don't try to
>>> delete or zero them. If you think they really need to be deleted, it
>>> should not be done in csoundReset but in an atexit handler. For a
>>> process, they'll just go away when the process exits. For different
>>> instances of Csound in the same process, these mutexes should in fact
>>> be global to the process.
>>>
>>> Regards,
>>> Mike
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Thu, Dec 29, 2016 at 11:43 AM, Steven Yi  wrote:
>>>> I think John and I are referring to these uses of static mutex locks:
>>>>
>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L138-L139
>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>>>
>>>>
>>>>
>>>> On Thu, Dec 29, 2016 at 11:33 AM, Michael Gogins
>>>>  wrote:
>>>>> If you are talking about the signal flow graph opcodes, the code is
>>>>> re-entrant. There are indeed static tables of objects, but those
>>>>> objects are mapped by Csound instance as well as object instance.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> -----------------------------------------------------
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://michaelgogins.tumblr.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>>
>>>>> On Thu, Dec 29, 2016 at 10:40 AM, jpff  wrote:
>>>>>> Looks as if flowgraph uses data statics which we removed throughout csound
>>>>>> to make it re-entrant.   So it is unsafe
>>>>>>
>>>>>>
>>>>>> On Thu, 29 Dec 2016, Steven Yi wrote:
>>>>>>
>>>>>>>
>>>>>>> Would there be problems if multiple Csound instances are created?
>>>>>>> (thinking of
>>>>>>> how Rory uses Csound instances in Cabbage)
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Dec 29, 2016, 5:11 AM Victor Lazzarini 
>>>>>>> wrote:
>>>>>>>      This should be ok, since it happens on reset. I had to add those
>>>>>>>      lines because a leak was reported on csoundReset().
>>>>>>>
>>>>>>>      Victor Lazzarini
>>>>>>>      Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>      Maynooth University
>>>>>>>      Ireland
>>>>>>>
>>>>>>>> On 29 Dec 2016, at 02:31, Steven Yi  wrote:
>>>>>>>>
>>>>>>>> After running a git bisect session, the commit that was found
>>>>>>>      where
>>>>>>>> the problem started is this one:
>>>>>>>>
>>>>>>>
>>>>>>>> https://github.com/csound/csound/commit/60593c7807cd4d0931254843db2421da6d4dc
>>>>>>>      652
>>>>>>>>
>>>>>>>> I've pushed a fix at:
>>>>>>>>
>>>>>>>
>>>>>>>> https://github.com/csound/csound/commit/a02db25c3d2bc3ab0d89d4f9a6487bf325d84
>>>>>>>      46e
>>>>>>>>
>>>>>>>> The change seems to make things work as exepcted.  Victor: Could
>>>>>>>      you
>>>>>>>> review this fix? I think because the values were only freed but
>>>>>>>      not
>>>>>>>> zeroed, it caused problems on second and third runs and resulted
>>>>>>>      in an
>>>>>>>> attempt to free a value that was freed before.  However, I'm
>>>>>>>      concerned
>>>>>>>> about this code being thread-safe, even before my fix.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Wed, Dec 28, 2016 at 7:29 PM, Steven Yi 
>>>>>>>      wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Just FYI, Menno reported on the Blue list that there's a
>>>>>>>      problem with
>>>>>>>>> Csound.  WIth the latest from GIT, Blue crashes always after
>>>>>>>      the 3rd
>>>>>>>>> time running Csound (via API).  The email thread has more
>>>>>>>      information
>>>>>>>>> here:
>>>>>>>>>
>>>>>>>>> https://sourceforge.net/p/bluemusic/mailman/message/35569588/
>>>>>>>>>
>>>>>>>>> I've been able to reproduce the problem here.  Rewinding to
>>>>>>>      commit
>>>>>>>>> 2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I
>>>>>>>      can run
>>>>>>>>> Csound multiple times within Blue without problem.
>>>>>>>>>
>>>>>>>>> I don't have much more information yet beside that I see that
>>>>>>>      the
>>>>>>>>> crash happens restting Csound.  I'll take a look at using git
>>>>>>>      bisect
>>>>>>>>> to see if I can find the problem.
>>>>>>>>>
>>>>>>>>> steven
>>>>>>>
>>>>>>>

Both the jack opcodes and the jack backend leak memory. I think that is to do with the Jack lib, not Csound. I fixed all the leaks in Csound.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 29 Dec 2016, at 20:12, Michael Gogins  wrote:
> 
> I understand about the memory leak, but my view was that this is an
> acceptable tradeoff: Either there is a small memory leak but multiple
> instances of Csound can run in the same process using the signal
> flowgraph opcodes, as with Cabbage plugins or CsoundVST in a digital
> audio workstation, or the signal flow graph opcodes cannot be used in
> a DAW but there is no memory leak from these mutexes.
> 
> However, a better option is to use an atexit handler for these global
> statics. At any rate, I will debug this and find out what is really
> going on.
> 
> The scale of memory growth reported in issue 722 is vastly greater
> than that reported by valgrind. Does anybody have an answer for that?
> Does it occur only with soundfile output or only for real-time audio
> output?
> 
> In issue 722,do you mean the jack driver for command-line options, or
> the Jacko opcodes?
> 
> Regards,
> Mike
> 
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
> 
> 
> On Thu, Dec 29, 2016 at 12:45 PM, Victor Lazzarini
>  wrote:
>> They needed to be cleared because they were causing memory leaks every time
>> Csound is reset. I chased all of these leaks and there are none now (at least on OSX/Linux).
>> 
>> https://github.com/csound/csound/issues/722
>> 
>> Even if we are not using the opcodes, the loading and unloading process will leak memory.
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>> 
>>> On 29 Dec 2016, at 17:03, Michael Gogins  wrote:
>>> 
>>> Got it, thanks.
>>> 
>>> Yes, that's a problem. The mutexes are supposed to protect the data
>>> tables from data races or overwrites between different instances of
>>> Csound, but of course if the module is destroyed by one instance while
>>> being used by another instance, the current code will not work. To
>>> precise, the current code is fine for different instances of Csound
>>> that run in different processes, but if there are different instances
>>> of Csound in the same process, then there is a problem.
>>> 
>>> The best solution is just to leave these variables alone. Don't try to
>>> delete or zero them. If you think they really need to be deleted, it
>>> should not be done in csoundReset but in an atexit handler. For a
>>> process, they'll just go away when the process exits. For different
>>> instances of Csound in the same process, these mutexes should in fact
>>> be global to the process.
>>> 
>>> Regards,
>>> Mike
>>> 
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>> 
>>> 
>>>> On Thu, Dec 29, 2016 at 11:43 AM, Steven Yi  wrote:
>>>> I think John and I are referring to these uses of static mutex locks:
>>>> 
>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L138-L139
>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>>> 
>>>> 
>>>> 
>>>> On Thu, Dec 29, 2016 at 11:33 AM, Michael Gogins
>>>>  wrote:
>>>>> If you are talking about the signal flow graph opcodes, the code is
>>>>> re-entrant. There are indeed static tables of objects, but those
>>>>> objects are mapped by Csound instance as well as object instance.
>>>>> 
>>>>> Regards,
>>>>> Mike
>>>>> 
>>>>> -----------------------------------------------------
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://michaelgogins.tumblr.com
>>>>> Michael dot Gogins at gmail dot com
>>>>> 
>>>>> 
>>>>>> On Thu, Dec 29, 2016 at 10:40 AM, jpff  wrote:
>>>>>> Looks as if flowgraph uses data statics which we removed throughout csound
>>>>>> to make it re-entrant.   So it is unsafe
>>>>>> 
>>>>>> 
>>>>>>> On Thu, 29 Dec 2016, Steven Yi wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> Would there be problems if multiple Csound instances are created?
>>>>>>> (thinking of
>>>>>>> how Rory uses Csound instances in Cabbage)
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Dec 29, 2016, 5:11 AM Victor Lazzarini 
>>>>>>> wrote:
>>>>>>>     This should be ok, since it happens on reset. I had to add those
>>>>>>>     lines because a leak was reported on csoundReset().
>>>>>>> 
>>>>>>>     Victor Lazzarini
>>>>>>>     Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>     Maynooth University
>>>>>>>     Ireland
>>>>>>> 
>>>>>>>> On 29 Dec 2016, at 02:31, Steven Yi  wrote:
>>>>>>>> 
>>>>>>>> After running a git bisect session, the commit that was found
>>>>>>>     where
>>>>>>>> the problem started is this one:
>>>>>>>> 
>>>>>>> 
>>>>>>>> https://github.com/csound/csound/commit/60593c7807cd4d0931254843db2421da6d4dc
>>>>>>>     652
>>>>>>>> 
>>>>>>>> I've pushed a fix at:
>>>>>>>> 
>>>>>>> 
>>>>>>>> https://github.com/csound/csound/commit/a02db25c3d2bc3ab0d89d4f9a6487bf325d84
>>>>>>>     46e
>>>>>>>> 
>>>>>>>> The change seems to make things work as exepcted.  Victor: Could
>>>>>>>     you
>>>>>>>> review this fix? I think because the values were only freed but
>>>>>>>     not
>>>>>>>> zeroed, it caused problems on second and third runs and resulted
>>>>>>>     in an
>>>>>>>> attempt to free a value that was freed before.  However, I'm
>>>>>>>     concerned
>>>>>>>> about this code being thread-safe, even before my fix.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Wed, Dec 28, 2016 at 7:29 PM, Steven Yi 
>>>>>>>     wrote:
>>>>>>>>> Hi All,
>>>>>>>>> 
>>>>>>>>> Just FYI, Menno reported on the Blue list that there's a
>>>>>>>     problem with
>>>>>>>>> Csound.  WIth the latest from GIT, Blue crashes always after
>>>>>>>     the 3rd
>>>>>>>>> time running Csound (via API).  The email thread has more
>>>>>>>     information
>>>>>>>>> here:
>>>>>>>>> 
>>>>>>>>> https://sourceforge.net/p/bluemusic/mailman/message/35569588/
>>>>>>>>> 
>>>>>>>>> I've been able to reproduce the problem here.  Rewinding to
>>>>>>>     commit
>>>>>>>>> 2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I
>>>>>>>     can run
>>>>>>>>> Csound multiple times within Blue without problem.
>>>>>>>>> 
>>>>>>>>> I don't have much more information yet beside that I see that
>>>>>>>     the
>>>>>>>>> crash happens restting Csound.  I'll take a look at using git
>>>>>>>     bisect
>>>>>>>>> to see if I can find the problem.
>>>>>>>>> 
>>>>>>>>> steven
>>>>>>> 
>>>>>>> 

My code for signalflowgraph.cpp (and in other places) is based on a
false assumption about static variables in a process.

I know that when a process loads a shared library, the operating
system creates a copy of all static variables for the code in that
shared library.

I assumed this meant that if the same process loads the same shared
library multiple times, just one copy of the static variables is used.

I have now read and proved by testing that in fact, the operating
system creates a new copy of static variables in a module each time
that module is loaded, even if it is re-loaded into the same process.

I will change my code to reflect this.

There isn't, therefore, actually any problem with multiple instances
of Csound in the same process.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Thu, Dec 29, 2016 at 3:12 PM, Michael Gogins
 wrote:
> I understand about the memory leak, but my view was that this is an
> acceptable tradeoff: Either there is a small memory leak but multiple
> instances of Csound can run in the same process using the signal
> flowgraph opcodes, as with Cabbage plugins or CsoundVST in a digital
> audio workstation, or the signal flow graph opcodes cannot be used in
> a DAW but there is no memory leak from these mutexes.
>
> However, a better option is to use an atexit handler for these global
> statics. At any rate, I will debug this and find out what is really
> going on.
>
> The scale of memory growth reported in issue 722 is vastly greater
> than that reported by valgrind. Does anybody have an answer for that?
> Does it occur only with soundfile output or only for real-time audio
> output?
>
> In issue 722,do you mean the jack driver for command-line options, or
> the Jacko opcodes?
>
> Regards,
> Mike
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Thu, Dec 29, 2016 at 12:45 PM, Victor Lazzarini
>  wrote:
>> They needed to be cleared because they were causing memory leaks every time
>> Csound is reset. I chased all of these leaks and there are none now (at least on OSX/Linux).
>>
>> https://github.com/csound/csound/issues/722
>>
>> Even if we are not using the opcodes, the loading and unloading process will leak memory.
>> ========================
>> Prof. Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>>
>>> On 29 Dec 2016, at 17:03, Michael Gogins  wrote:
>>>
>>> Got it, thanks.
>>>
>>> Yes, that's a problem. The mutexes are supposed to protect the data
>>> tables from data races or overwrites between different instances of
>>> Csound, but of course if the module is destroyed by one instance while
>>> being used by another instance, the current code will not work. To
>>> precise, the current code is fine for different instances of Csound
>>> that run in different processes, but if there are different instances
>>> of Csound in the same process, then there is a problem.
>>>
>>> The best solution is just to leave these variables alone. Don't try to
>>> delete or zero them. If you think they really need to be deleted, it
>>> should not be done in csoundReset but in an atexit handler. For a
>>> process, they'll just go away when the process exits. For different
>>> instances of Csound in the same process, these mutexes should in fact
>>> be global to the process.
>>>
>>> Regards,
>>> Mike
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Thu, Dec 29, 2016 at 11:43 AM, Steven Yi  wrote:
>>>> I think John and I are referring to these uses of static mutex locks:
>>>>
>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L138-L139
>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>>>
>>>>
>>>>
>>>> On Thu, Dec 29, 2016 at 11:33 AM, Michael Gogins
>>>>  wrote:
>>>>> If you are talking about the signal flow graph opcodes, the code is
>>>>> re-entrant. There are indeed static tables of objects, but those
>>>>> objects are mapped by Csound instance as well as object instance.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> -----------------------------------------------------
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://michaelgogins.tumblr.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>>
>>>>> On Thu, Dec 29, 2016 at 10:40 AM, jpff  wrote:
>>>>>> Looks as if flowgraph uses data statics which we removed throughout csound
>>>>>> to make it re-entrant.   So it is unsafe
>>>>>>
>>>>>>
>>>>>> On Thu, 29 Dec 2016, Steven Yi wrote:
>>>>>>
>>>>>>>
>>>>>>> Would there be problems if multiple Csound instances are created?
>>>>>>> (thinking of
>>>>>>> how Rory uses Csound instances in Cabbage)
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Dec 29, 2016, 5:11 AM Victor Lazzarini 
>>>>>>> wrote:
>>>>>>>      This should be ok, since it happens on reset. I had to add those
>>>>>>>      lines because a leak was reported on csoundReset().
>>>>>>>
>>>>>>>      Victor Lazzarini
>>>>>>>      Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>      Maynooth University
>>>>>>>      Ireland
>>>>>>>
>>>>>>>> On 29 Dec 2016, at 02:31, Steven Yi  wrote:
>>>>>>>>
>>>>>>>> After running a git bisect session, the commit that was found
>>>>>>>      where
>>>>>>>> the problem started is this one:
>>>>>>>>
>>>>>>>
>>>>>>>> https://github.com/csound/csound/commit/60593c7807cd4d0931254843db2421da6d4dc
>>>>>>>      652
>>>>>>>>
>>>>>>>> I've pushed a fix at:
>>>>>>>>
>>>>>>>
>>>>>>>> https://github.com/csound/csound/commit/a02db25c3d2bc3ab0d89d4f9a6487bf325d84
>>>>>>>      46e
>>>>>>>>
>>>>>>>> The change seems to make things work as exepcted.  Victor: Could
>>>>>>>      you
>>>>>>>> review this fix? I think because the values were only freed but
>>>>>>>      not
>>>>>>>> zeroed, it caused problems on second and third runs and resulted
>>>>>>>      in an
>>>>>>>> attempt to free a value that was freed before.  However, I'm
>>>>>>>      concerned
>>>>>>>> about this code being thread-safe, even before my fix.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Wed, Dec 28, 2016 at 7:29 PM, Steven Yi 
>>>>>>>      wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Just FYI, Menno reported on the Blue list that there's a
>>>>>>>      problem with
>>>>>>>>> Csound.  WIth the latest from GIT, Blue crashes always after
>>>>>>>      the 3rd
>>>>>>>>> time running Csound (via API).  The email thread has more
>>>>>>>      information
>>>>>>>>> here:
>>>>>>>>>
>>>>>>>>> https://sourceforge.net/p/bluemusic/mailman/message/35569588/
>>>>>>>>>
>>>>>>>>> I've been able to reproduce the problem here.  Rewinding to
>>>>>>>      commit
>>>>>>>>> 2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I
>>>>>>>      can run
>>>>>>>>> Csound multiple times within Blue without problem.
>>>>>>>>>
>>>>>>>>> I don't have much more information yet beside that I see that
>>>>>>>      the
>>>>>>>>> crash happens restting Csound.  I'll take a look at using git
>>>>>>>      bisect
>>>>>>>>> to see if I can find the problem.
>>>>>>>>>
>>>>>>>>> steven
>>>>>>>
>>>>>>>

Thanks Michael for researching that; is this the case for all OS's?
I'll test on Windows and Linux with Blue once there are code changes
to test.

On Thu, Dec 29, 2016 at 7:00 PM, Michael Gogins
 wrote:
> My code for signalflowgraph.cpp (and in other places) is based on a
> false assumption about static variables in a process.
>
> I know that when a process loads a shared library, the operating
> system creates a copy of all static variables for the code in that
> shared library.
>
> I assumed this meant that if the same process loads the same shared
> library multiple times, just one copy of the static variables is used.
>
> I have now read and proved by testing that in fact, the operating
> system creates a new copy of static variables in a module each time
> that module is loaded, even if it is re-loaded into the same process.
>
> I will change my code to reflect this.
>
> There isn't, therefore, actually any problem with multiple instances
> of Csound in the same process.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Thu, Dec 29, 2016 at 3:12 PM, Michael Gogins
>  wrote:
>> I understand about the memory leak, but my view was that this is an
>> acceptable tradeoff: Either there is a small memory leak but multiple
>> instances of Csound can run in the same process using the signal
>> flowgraph opcodes, as with Cabbage plugins or CsoundVST in a digital
>> audio workstation, or the signal flow graph opcodes cannot be used in
>> a DAW but there is no memory leak from these mutexes.
>>
>> However, a better option is to use an atexit handler for these global
>> statics. At any rate, I will debug this and find out what is really
>> going on.
>>
>> The scale of memory growth reported in issue 722 is vastly greater
>> than that reported by valgrind. Does anybody have an answer for that?
>> Does it occur only with soundfile output or only for real-time audio
>> output?
>>
>> In issue 722,do you mean the jack driver for command-line options, or
>> the Jacko opcodes?
>>
>> Regards,
>> Mike
>>
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Thu, Dec 29, 2016 at 12:45 PM, Victor Lazzarini
>>  wrote:
>>> They needed to be cleared because they were causing memory leaks every time
>>> Csound is reset. I chased all of these leaks and there are none now (at least on OSX/Linux).
>>>
>>> https://github.com/csound/csound/issues/722
>>>
>>> Even if we are not using the opcodes, the loading and unloading process will leak memory.
>>> ========================
>>> Prof. Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>>
>>>> On 29 Dec 2016, at 17:03, Michael Gogins  wrote:
>>>>
>>>> Got it, thanks.
>>>>
>>>> Yes, that's a problem. The mutexes are supposed to protect the data
>>>> tables from data races or overwrites between different instances of
>>>> Csound, but of course if the module is destroyed by one instance while
>>>> being used by another instance, the current code will not work. To
>>>> precise, the current code is fine for different instances of Csound
>>>> that run in different processes, but if there are different instances
>>>> of Csound in the same process, then there is a problem.
>>>>
>>>> The best solution is just to leave these variables alone. Don't try to
>>>> delete or zero them. If you think they really need to be deleted, it
>>>> should not be done in csoundReset but in an atexit handler. For a
>>>> process, they'll just go away when the process exits. For different
>>>> instances of Csound in the same process, these mutexes should in fact
>>>> be global to the process.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> -----------------------------------------------------
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://michaelgogins.tumblr.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>>
>>>> On Thu, Dec 29, 2016 at 11:43 AM, Steven Yi  wrote:
>>>>> I think John and I are referring to these uses of static mutex locks:
>>>>>
>>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L138-L139
>>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Dec 29, 2016 at 11:33 AM, Michael Gogins
>>>>>  wrote:
>>>>>> If you are talking about the signal flow graph opcodes, the code is
>>>>>> re-entrant. There are indeed static tables of objects, but those
>>>>>> objects are mapped by Csound instance as well as object instance.
>>>>>>
>>>>>> Regards,
>>>>>> Mike
>>>>>>
>>>>>> -----------------------------------------------------
>>>>>> Michael Gogins
>>>>>> Irreducible Productions
>>>>>> http://michaelgogins.tumblr.com
>>>>>> Michael dot Gogins at gmail dot com
>>>>>>
>>>>>>
>>>>>> On Thu, Dec 29, 2016 at 10:40 AM, jpff  wrote:
>>>>>>> Looks as if flowgraph uses data statics which we removed throughout csound
>>>>>>> to make it re-entrant.   So it is unsafe
>>>>>>>
>>>>>>>
>>>>>>> On Thu, 29 Dec 2016, Steven Yi wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Would there be problems if multiple Csound instances are created?
>>>>>>>> (thinking of
>>>>>>>> how Rory uses Csound instances in Cabbage)
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Dec 29, 2016, 5:11 AM Victor Lazzarini 
>>>>>>>> wrote:
>>>>>>>>      This should be ok, since it happens on reset. I had to add those
>>>>>>>>      lines because a leak was reported on csoundReset().
>>>>>>>>
>>>>>>>>      Victor Lazzarini
>>>>>>>>      Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>>      Maynooth University
>>>>>>>>      Ireland
>>>>>>>>
>>>>>>>>> On 29 Dec 2016, at 02:31, Steven Yi  wrote:
>>>>>>>>>
>>>>>>>>> After running a git bisect session, the commit that was found
>>>>>>>>      where
>>>>>>>>> the problem started is this one:
>>>>>>>>>
>>>>>>>>
>>>>>>>>> https://github.com/csound/csound/commit/60593c7807cd4d0931254843db2421da6d4dc
>>>>>>>>      652
>>>>>>>>>
>>>>>>>>> I've pushed a fix at:
>>>>>>>>>
>>>>>>>>
>>>>>>>>> https://github.com/csound/csound/commit/a02db25c3d2bc3ab0d89d4f9a6487bf325d84
>>>>>>>>      46e
>>>>>>>>>
>>>>>>>>> The change seems to make things work as exepcted.  Victor: Could
>>>>>>>>      you
>>>>>>>>> review this fix? I think because the values were only freed but
>>>>>>>>      not
>>>>>>>>> zeroed, it caused problems on second and third runs and resulted
>>>>>>>>      in an
>>>>>>>>> attempt to free a value that was freed before.  However, I'm
>>>>>>>>      concerned
>>>>>>>>> about this code being thread-safe, even before my fix.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Wed, Dec 28, 2016 at 7:29 PM, Steven Yi 
>>>>>>>>      wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> Just FYI, Menno reported on the Blue list that there's a
>>>>>>>>      problem with
>>>>>>>>>> Csound.  WIth the latest from GIT, Blue crashes always after
>>>>>>>>      the 3rd
>>>>>>>>>> time running Csound (via API).  The email thread has more
>>>>>>>>      information
>>>>>>>>>> here:
>>>>>>>>>>
>>>>>>>>>> https://sourceforge.net/p/bluemusic/mailman/message/35569588/
>>>>>>>>>>
>>>>>>>>>> I've been able to reproduce the problem here.  Rewinding to
>>>>>>>>      commit
>>>>>>>>>> 2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I
>>>>>>>>      can run
>>>>>>>>>> Csound multiple times within Blue without problem.
>>>>>>>>>>
>>>>>>>>>> I don't have much more information yet beside that I see that
>>>>>>>>      the
>>>>>>>>>> crash happens restting Csound.  I'll take a look at using git
>>>>>>>>      bisect
>>>>>>>>>> to see if I can find the problem.
>>>>>>>>>>
>>>>>>>>>> steven
>>>>>>>>
>>>>>>>>

I will find if it is the case on WIndows by experiment.

Best,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Thu, Dec 29, 2016 at 8:33 PM, Steven Yi  wrote:
> Thanks Michael for researching that; is this the case for all OS's?
> I'll test on Windows and Linux with Blue once there are code changes
> to test.
>
> On Thu, Dec 29, 2016 at 7:00 PM, Michael Gogins
>  wrote:
>> My code for signalflowgraph.cpp (and in other places) is based on a
>> false assumption about static variables in a process.
>>
>> I know that when a process loads a shared library, the operating
>> system creates a copy of all static variables for the code in that
>> shared library.
>>
>> I assumed this meant that if the same process loads the same shared
>> library multiple times, just one copy of the static variables is used.
>>
>> I have now read and proved by testing that in fact, the operating
>> system creates a new copy of static variables in a module each time
>> that module is loaded, even if it is re-loaded into the same process.
>>
>> I will change my code to reflect this.
>>
>> There isn't, therefore, actually any problem with multiple instances
>> of Csound in the same process.
>>
>> Regards,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Thu, Dec 29, 2016 at 3:12 PM, Michael Gogins
>>  wrote:
>>> I understand about the memory leak, but my view was that this is an
>>> acceptable tradeoff: Either there is a small memory leak but multiple
>>> instances of Csound can run in the same process using the signal
>>> flowgraph opcodes, as with Cabbage plugins or CsoundVST in a digital
>>> audio workstation, or the signal flow graph opcodes cannot be used in
>>> a DAW but there is no memory leak from these mutexes.
>>>
>>> However, a better option is to use an atexit handler for these global
>>> statics. At any rate, I will debug this and find out what is really
>>> going on.
>>>
>>> The scale of memory growth reported in issue 722 is vastly greater
>>> than that reported by valgrind. Does anybody have an answer for that?
>>> Does it occur only with soundfile output or only for real-time audio
>>> output?
>>>
>>> In issue 722,do you mean the jack driver for command-line options, or
>>> the Jacko opcodes?
>>>
>>> Regards,
>>> Mike
>>>
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Thu, Dec 29, 2016 at 12:45 PM, Victor Lazzarini
>>>  wrote:
>>>> They needed to be cleared because they were causing memory leaks every time
>>>> Csound is reset. I chased all of these leaks and there are none now (at least on OSX/Linux).
>>>>
>>>> https://github.com/csound/csound/issues/722
>>>>
>>>> Even if we are not using the opcodes, the loading and unloading process will leak memory.
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952
>>>>
>>>>> On 29 Dec 2016, at 17:03, Michael Gogins  wrote:
>>>>>
>>>>> Got it, thanks.
>>>>>
>>>>> Yes, that's a problem. The mutexes are supposed to protect the data
>>>>> tables from data races or overwrites between different instances of
>>>>> Csound, but of course if the module is destroyed by one instance while
>>>>> being used by another instance, the current code will not work. To
>>>>> precise, the current code is fine for different instances of Csound
>>>>> that run in different processes, but if there are different instances
>>>>> of Csound in the same process, then there is a problem.
>>>>>
>>>>> The best solution is just to leave these variables alone. Don't try to
>>>>> delete or zero them. If you think they really need to be deleted, it
>>>>> should not be done in csoundReset but in an atexit handler. For a
>>>>> process, they'll just go away when the process exits. For different
>>>>> instances of Csound in the same process, these mutexes should in fact
>>>>> be global to the process.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> -----------------------------------------------------
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://michaelgogins.tumblr.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>>
>>>>> On Thu, Dec 29, 2016 at 11:43 AM, Steven Yi  wrote:
>>>>>> I think John and I are referring to these uses of static mutex locks:
>>>>>>
>>>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L138-L139
>>>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Dec 29, 2016 at 11:33 AM, Michael Gogins
>>>>>>  wrote:
>>>>>>> If you are talking about the signal flow graph opcodes, the code is
>>>>>>> re-entrant. There are indeed static tables of objects, but those
>>>>>>> objects are mapped by Csound instance as well as object instance.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mike
>>>>>>>
>>>>>>> -----------------------------------------------------
>>>>>>> Michael Gogins
>>>>>>> Irreducible Productions
>>>>>>> http://michaelgogins.tumblr.com
>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Dec 29, 2016 at 10:40 AM, jpff  wrote:
>>>>>>>> Looks as if flowgraph uses data statics which we removed throughout csound
>>>>>>>> to make it re-entrant.   So it is unsafe
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, 29 Dec 2016, Steven Yi wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Would there be problems if multiple Csound instances are created?
>>>>>>>>> (thinking of
>>>>>>>>> how Rory uses Csound instances in Cabbage)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Dec 29, 2016, 5:11 AM Victor Lazzarini 
>>>>>>>>> wrote:
>>>>>>>>>      This should be ok, since it happens on reset. I had to add those
>>>>>>>>>      lines because a leak was reported on csoundReset().
>>>>>>>>>
>>>>>>>>>      Victor Lazzarini
>>>>>>>>>      Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>>>      Maynooth University
>>>>>>>>>      Ireland
>>>>>>>>>
>>>>>>>>>> On 29 Dec 2016, at 02:31, Steven Yi  wrote:
>>>>>>>>>>
>>>>>>>>>> After running a git bisect session, the commit that was found
>>>>>>>>>      where
>>>>>>>>>> the problem started is this one:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> https://github.com/csound/csound/commit/60593c7807cd4d0931254843db2421da6d4dc
>>>>>>>>>      652
>>>>>>>>>>
>>>>>>>>>> I've pushed a fix at:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> https://github.com/csound/csound/commit/a02db25c3d2bc3ab0d89d4f9a6487bf325d84
>>>>>>>>>      46e
>>>>>>>>>>
>>>>>>>>>> The change seems to make things work as exepcted.  Victor: Could
>>>>>>>>>      you
>>>>>>>>>> review this fix? I think because the values were only freed but
>>>>>>>>>      not
>>>>>>>>>> zeroed, it caused problems on second and third runs and resulted
>>>>>>>>>      in an
>>>>>>>>>> attempt to free a value that was freed before.  However, I'm
>>>>>>>>>      concerned
>>>>>>>>>> about this code being thread-safe, even before my fix.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Wed, Dec 28, 2016 at 7:29 PM, Steven Yi 
>>>>>>>>>      wrote:
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> Just FYI, Menno reported on the Blue list that there's a
>>>>>>>>>      problem with
>>>>>>>>>>> Csound.  WIth the latest from GIT, Blue crashes always after
>>>>>>>>>      the 3rd
>>>>>>>>>>> time running Csound (via API).  The email thread has more
>>>>>>>>>      information
>>>>>>>>>>> here:
>>>>>>>>>>>
>>>>>>>>>>> https://sourceforge.net/p/bluemusic/mailman/message/35569588/
>>>>>>>>>>>
>>>>>>>>>>> I've been able to reproduce the problem here.  Rewinding to
>>>>>>>>>      commit
>>>>>>>>>>> 2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I
>>>>>>>>>      can run
>>>>>>>>>>> Csound multiple times within Blue without problem.
>>>>>>>>>>>
>>>>>>>>>>> I don't have much more information yet beside that I see that
>>>>>>>>>      the
>>>>>>>>>>> crash happens restting Csound.  I'll take a look at using git
>>>>>>>>>      bisect
>>>>>>>>>>> to see if I can find the problem.
>>>>>>>>>>>
>>>>>>>>>>> steven
>>>>>>>>>
>>>>>>>>>

I have done to the experiment. The behavior is the same on Windows:
global variables in shared libraries are created as fresh copies in
each module that is loaded.

Accordingly, I changed the code in signalflowgraph.cpp. I retained
your mutex creation and locking/unlocking code, but I query the global
variables only on module initializaton, and set them to global
variables, which simplifies the code and probably gives slightly
better performance.

Best,
Mike



-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Thu, Dec 29, 2016 at 8:39 PM, Michael Gogins
 wrote:
> I will find if it is the case on WIndows by experiment.
>
> Best,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Thu, Dec 29, 2016 at 8:33 PM, Steven Yi  wrote:
>> Thanks Michael for researching that; is this the case for all OS's?
>> I'll test on Windows and Linux with Blue once there are code changes
>> to test.
>>
>> On Thu, Dec 29, 2016 at 7:00 PM, Michael Gogins
>>  wrote:
>>> My code for signalflowgraph.cpp (and in other places) is based on a
>>> false assumption about static variables in a process.
>>>
>>> I know that when a process loads a shared library, the operating
>>> system creates a copy of all static variables for the code in that
>>> shared library.
>>>
>>> I assumed this meant that if the same process loads the same shared
>>> library multiple times, just one copy of the static variables is used.
>>>
>>> I have now read and proved by testing that in fact, the operating
>>> system creates a new copy of static variables in a module each time
>>> that module is loaded, even if it is re-loaded into the same process.
>>>
>>> I will change my code to reflect this.
>>>
>>> There isn't, therefore, actually any problem with multiple instances
>>> of Csound in the same process.
>>>
>>> Regards,
>>> Mike
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Thu, Dec 29, 2016 at 3:12 PM, Michael Gogins
>>>  wrote:
>>>> I understand about the memory leak, but my view was that this is an
>>>> acceptable tradeoff: Either there is a small memory leak but multiple
>>>> instances of Csound can run in the same process using the signal
>>>> flowgraph opcodes, as with Cabbage plugins or CsoundVST in a digital
>>>> audio workstation, or the signal flow graph opcodes cannot be used in
>>>> a DAW but there is no memory leak from these mutexes.
>>>>
>>>> However, a better option is to use an atexit handler for these global
>>>> statics. At any rate, I will debug this and find out what is really
>>>> going on.
>>>>
>>>> The scale of memory growth reported in issue 722 is vastly greater
>>>> than that reported by valgrind. Does anybody have an answer for that?
>>>> Does it occur only with soundfile output or only for real-time audio
>>>> output?
>>>>
>>>> In issue 722,do you mean the jack driver for command-line options, or
>>>> the Jacko opcodes?
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>>
>>>> -----------------------------------------------------
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://michaelgogins.tumblr.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>>
>>>> On Thu, Dec 29, 2016 at 12:45 PM, Victor Lazzarini
>>>>  wrote:
>>>>> They needed to be cleared because they were causing memory leaks every time
>>>>> Csound is reset. I chased all of these leaks and there are none now (at least on OSX/Linux).
>>>>>
>>>>> https://github.com/csound/csound/issues/722
>>>>>
>>>>> Even if we are not using the opcodes, the loading and unloading process will leak memory.
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952
>>>>>
>>>>>> On 29 Dec 2016, at 17:03, Michael Gogins  wrote:
>>>>>>
>>>>>> Got it, thanks.
>>>>>>
>>>>>> Yes, that's a problem. The mutexes are supposed to protect the data
>>>>>> tables from data races or overwrites between different instances of
>>>>>> Csound, but of course if the module is destroyed by one instance while
>>>>>> being used by another instance, the current code will not work. To
>>>>>> precise, the current code is fine for different instances of Csound
>>>>>> that run in different processes, but if there are different instances
>>>>>> of Csound in the same process, then there is a problem.
>>>>>>
>>>>>> The best solution is just to leave these variables alone. Don't try to
>>>>>> delete or zero them. If you think they really need to be deleted, it
>>>>>> should not be done in csoundReset but in an atexit handler. For a
>>>>>> process, they'll just go away when the process exits. For different
>>>>>> instances of Csound in the same process, these mutexes should in fact
>>>>>> be global to the process.
>>>>>>
>>>>>> Regards,
>>>>>> Mike
>>>>>>
>>>>>> -----------------------------------------------------
>>>>>> Michael Gogins
>>>>>> Irreducible Productions
>>>>>> http://michaelgogins.tumblr.com
>>>>>> Michael dot Gogins at gmail dot com
>>>>>>
>>>>>>
>>>>>> On Thu, Dec 29, 2016 at 11:43 AM, Steven Yi  wrote:
>>>>>>> I think John and I are referring to these uses of static mutex locks:
>>>>>>>
>>>>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L138-L139
>>>>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>>>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Dec 29, 2016 at 11:33 AM, Michael Gogins
>>>>>>>  wrote:
>>>>>>>> If you are talking about the signal flow graph opcodes, the code is
>>>>>>>> re-entrant. There are indeed static tables of objects, but those
>>>>>>>> objects are mapped by Csound instance as well as object instance.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> -----------------------------------------------------
>>>>>>>> Michael Gogins
>>>>>>>> Irreducible Productions
>>>>>>>> http://michaelgogins.tumblr.com
>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Dec 29, 2016 at 10:40 AM, jpff  wrote:
>>>>>>>>> Looks as if flowgraph uses data statics which we removed throughout csound
>>>>>>>>> to make it re-entrant.   So it is unsafe
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, 29 Dec 2016, Steven Yi wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Would there be problems if multiple Csound instances are created?
>>>>>>>>>> (thinking of
>>>>>>>>>> how Rory uses Csound instances in Cabbage)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Dec 29, 2016, 5:11 AM Victor Lazzarini 
>>>>>>>>>> wrote:
>>>>>>>>>>      This should be ok, since it happens on reset. I had to add those
>>>>>>>>>>      lines because a leak was reported on csoundReset().
>>>>>>>>>>
>>>>>>>>>>      Victor Lazzarini
>>>>>>>>>>      Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>>>>      Maynooth University
>>>>>>>>>>      Ireland
>>>>>>>>>>
>>>>>>>>>>> On 29 Dec 2016, at 02:31, Steven Yi  wrote:
>>>>>>>>>>>
>>>>>>>>>>> After running a git bisect session, the commit that was found
>>>>>>>>>>      where
>>>>>>>>>>> the problem started is this one:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> https://github.com/csound/csound/commit/60593c7807cd4d0931254843db2421da6d4dc
>>>>>>>>>>      652
>>>>>>>>>>>
>>>>>>>>>>> I've pushed a fix at:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> https://github.com/csound/csound/commit/a02db25c3d2bc3ab0d89d4f9a6487bf325d84
>>>>>>>>>>      46e
>>>>>>>>>>>
>>>>>>>>>>> The change seems to make things work as exepcted.  Victor: Could
>>>>>>>>>>      you
>>>>>>>>>>> review this fix? I think because the values were only freed but
>>>>>>>>>>      not
>>>>>>>>>>> zeroed, it caused problems on second and third runs and resulted
>>>>>>>>>>      in an
>>>>>>>>>>> attempt to free a value that was freed before.  However, I'm
>>>>>>>>>>      concerned
>>>>>>>>>>> about this code being thread-safe, even before my fix.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Dec 28, 2016 at 7:29 PM, Steven Yi 
>>>>>>>>>>      wrote:
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>
>>>>>>>>>>>> Just FYI, Menno reported on the Blue list that there's a
>>>>>>>>>>      problem with
>>>>>>>>>>>> Csound.  WIth the latest from GIT, Blue crashes always after
>>>>>>>>>>      the 3rd
>>>>>>>>>>>> time running Csound (via API).  The email thread has more
>>>>>>>>>>      information
>>>>>>>>>>>> here:
>>>>>>>>>>>>
>>>>>>>>>>>> https://sourceforge.net/p/bluemusic/mailman/message/35569588/
>>>>>>>>>>>>
>>>>>>>>>>>> I've been able to reproduce the problem here.  Rewinding to
>>>>>>>>>>      commit
>>>>>>>>>>>> 2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I
>>>>>>>>>>      can run
>>>>>>>>>>>> Csound multiple times within Blue without problem.
>>>>>>>>>>>>
>>>>>>>>>>>> I don't have much more information yet beside that I see that
>>>>>>>>>>      the
>>>>>>>>>>>> crash happens restting Csound.  I'll take a look at using git
>>>>>>>>>>      bisect
>>>>>>>>>>>> to see if I can find the problem.
>>>>>>>>>>>>
>>>>>>>>>>>> steven
>>>>>>>>>>
>>>>>>>>>>

I'm not sure if the data needs to be kept in Csound's global vars now,
but regardless, I rebuilt the latest from GIT and things look good
here to run multiple times here on Windows with Blue.  It looks good
to go for me, but I'll push to Coverity to see if it finds anything
now.

Thanks!
steven

On Thu, Dec 29, 2016 at 9:55 PM, Michael Gogins
 wrote:
> I have done to the experiment. The behavior is the same on Windows:
> global variables in shared libraries are created as fresh copies in
> each module that is loaded.
>
> Accordingly, I changed the code in signalflowgraph.cpp. I retained
> your mutex creation and locking/unlocking code, but I query the global
> variables only on module initializaton, and set them to global
> variables, which simplifies the code and probably gives slightly
> better performance.
>
> Best,
> Mike
>
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Thu, Dec 29, 2016 at 8:39 PM, Michael Gogins
>  wrote:
>> I will find if it is the case on WIndows by experiment.
>>
>> Best,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Thu, Dec 29, 2016 at 8:33 PM, Steven Yi  wrote:
>>> Thanks Michael for researching that; is this the case for all OS's?
>>> I'll test on Windows and Linux with Blue once there are code changes
>>> to test.
>>>
>>> On Thu, Dec 29, 2016 at 7:00 PM, Michael Gogins
>>>  wrote:
>>>> My code for signalflowgraph.cpp (and in other places) is based on a
>>>> false assumption about static variables in a process.
>>>>
>>>> I know that when a process loads a shared library, the operating
>>>> system creates a copy of all static variables for the code in that
>>>> shared library.
>>>>
>>>> I assumed this meant that if the same process loads the same shared
>>>> library multiple times, just one copy of the static variables is used.
>>>>
>>>> I have now read and proved by testing that in fact, the operating
>>>> system creates a new copy of static variables in a module each time
>>>> that module is loaded, even if it is re-loaded into the same process.
>>>>
>>>> I will change my code to reflect this.
>>>>
>>>> There isn't, therefore, actually any problem with multiple instances
>>>> of Csound in the same process.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> -----------------------------------------------------
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://michaelgogins.tumblr.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>>
>>>> On Thu, Dec 29, 2016 at 3:12 PM, Michael Gogins
>>>>  wrote:
>>>>> I understand about the memory leak, but my view was that this is an
>>>>> acceptable tradeoff: Either there is a small memory leak but multiple
>>>>> instances of Csound can run in the same process using the signal
>>>>> flowgraph opcodes, as with Cabbage plugins or CsoundVST in a digital
>>>>> audio workstation, or the signal flow graph opcodes cannot be used in
>>>>> a DAW but there is no memory leak from these mutexes.
>>>>>
>>>>> However, a better option is to use an atexit handler for these global
>>>>> statics. At any rate, I will debug this and find out what is really
>>>>> going on.
>>>>>
>>>>> The scale of memory growth reported in issue 722 is vastly greater
>>>>> than that reported by valgrind. Does anybody have an answer for that?
>>>>> Does it occur only with soundfile output or only for real-time audio
>>>>> output?
>>>>>
>>>>> In issue 722,do you mean the jack driver for command-line options, or
>>>>> the Jacko opcodes?
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>>
>>>>> -----------------------------------------------------
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://michaelgogins.tumblr.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>>
>>>>> On Thu, Dec 29, 2016 at 12:45 PM, Victor Lazzarini
>>>>>  wrote:
>>>>>> They needed to be cleared because they were causing memory leaks every time
>>>>>> Csound is reset. I chased all of these leaks and there are none now (at least on OSX/Linux).
>>>>>>
>>>>>> https://github.com/csound/csound/issues/722
>>>>>>
>>>>>> Even if we are not using the opcodes, the loading and unloading process will leak memory.
>>>>>> ========================
>>>>>> Prof. Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952
>>>>>>
>>>>>>> On 29 Dec 2016, at 17:03, Michael Gogins  wrote:
>>>>>>>
>>>>>>> Got it, thanks.
>>>>>>>
>>>>>>> Yes, that's a problem. The mutexes are supposed to protect the data
>>>>>>> tables from data races or overwrites between different instances of
>>>>>>> Csound, but of course if the module is destroyed by one instance while
>>>>>>> being used by another instance, the current code will not work. To
>>>>>>> precise, the current code is fine for different instances of Csound
>>>>>>> that run in different processes, but if there are different instances
>>>>>>> of Csound in the same process, then there is a problem.
>>>>>>>
>>>>>>> The best solution is just to leave these variables alone. Don't try to
>>>>>>> delete or zero them. If you think they really need to be deleted, it
>>>>>>> should not be done in csoundReset but in an atexit handler. For a
>>>>>>> process, they'll just go away when the process exits. For different
>>>>>>> instances of Csound in the same process, these mutexes should in fact
>>>>>>> be global to the process.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mike
>>>>>>>
>>>>>>> -----------------------------------------------------
>>>>>>> Michael Gogins
>>>>>>> Irreducible Productions
>>>>>>> http://michaelgogins.tumblr.com
>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Dec 29, 2016 at 11:43 AM, Steven Yi  wrote:
>>>>>>>> I think John and I are referring to these uses of static mutex locks:
>>>>>>>>
>>>>>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L138-L139
>>>>>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>>>>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Dec 29, 2016 at 11:33 AM, Michael Gogins
>>>>>>>>  wrote:
>>>>>>>>> If you are talking about the signal flow graph opcodes, the code is
>>>>>>>>> re-entrant. There are indeed static tables of objects, but those
>>>>>>>>> objects are mapped by Csound instance as well as object instance.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>> -----------------------------------------------------
>>>>>>>>> Michael Gogins
>>>>>>>>> Irreducible Productions
>>>>>>>>> http://michaelgogins.tumblr.com
>>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Dec 29, 2016 at 10:40 AM, jpff  wrote:
>>>>>>>>>> Looks as if flowgraph uses data statics which we removed throughout csound
>>>>>>>>>> to make it re-entrant.   So it is unsafe
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, 29 Dec 2016, Steven Yi wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Would there be problems if multiple Csound instances are created?
>>>>>>>>>>> (thinking of
>>>>>>>>>>> how Rory uses Csound instances in Cabbage)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Dec 29, 2016, 5:11 AM Victor Lazzarini 
>>>>>>>>>>> wrote:
>>>>>>>>>>>      This should be ok, since it happens on reset. I had to add those
>>>>>>>>>>>      lines because a leak was reported on csoundReset().
>>>>>>>>>>>
>>>>>>>>>>>      Victor Lazzarini
>>>>>>>>>>>      Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>>>>>      Maynooth University
>>>>>>>>>>>      Ireland
>>>>>>>>>>>
>>>>>>>>>>>> On 29 Dec 2016, at 02:31, Steven Yi  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> After running a git bisect session, the commit that was found
>>>>>>>>>>>      where
>>>>>>>>>>>> the problem started is this one:
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> https://github.com/csound/csound/commit/60593c7807cd4d0931254843db2421da6d4dc
>>>>>>>>>>>      652
>>>>>>>>>>>>
>>>>>>>>>>>> I've pushed a fix at:
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> https://github.com/csound/csound/commit/a02db25c3d2bc3ab0d89d4f9a6487bf325d84
>>>>>>>>>>>      46e
>>>>>>>>>>>>
>>>>>>>>>>>> The change seems to make things work as exepcted.  Victor: Could
>>>>>>>>>>>      you
>>>>>>>>>>>> review this fix? I think because the values were only freed but
>>>>>>>>>>>      not
>>>>>>>>>>>> zeroed, it caused problems on second and third runs and resulted
>>>>>>>>>>>      in an
>>>>>>>>>>>> attempt to free a value that was freed before.  However, I'm
>>>>>>>>>>>      concerned
>>>>>>>>>>>> about this code being thread-safe, even before my fix.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Dec 28, 2016 at 7:29 PM, Steven Yi 
>>>>>>>>>>>      wrote:
>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Just FYI, Menno reported on the Blue list that there's a
>>>>>>>>>>>      problem with
>>>>>>>>>>>>> Csound.  WIth the latest from GIT, Blue crashes always after
>>>>>>>>>>>      the 3rd
>>>>>>>>>>>>> time running Csound (via API).  The email thread has more
>>>>>>>>>>>      information
>>>>>>>>>>>>> here:
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://sourceforge.net/p/bluemusic/mailman/message/35569588/
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've been able to reproduce the problem here.  Rewinding to
>>>>>>>>>>>      commit
>>>>>>>>>>>>> 2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I
>>>>>>>>>>>      can run
>>>>>>>>>>>>> Csound multiple times within Blue without problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don't have much more information yet beside that I see that
>>>>>>>>>>>      the
>>>>>>>>>>>>> crash happens restting Csound.  I'll take a look at using git
>>>>>>>>>>>      bisect
>>>>>>>>>>>>> to see if I can find the problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> steven
>>>>>>>>>>>
>>>>>>>>>>>

BTW: I just saw your last change.  This looked similar to the older
code from just before I made the change to use Csound's global var
system.  One thing is that I used void** because CreateGlobalVariable
takes a size of memory to allocate, and csound's Create_Mutex() is
supposed to be transparent with the void* being returned.  The code
prior to my changes only used void* which was simpler code, but did
not work so well with the Global var system.  If you're going to
change back to using a static var within the module, it'd probably be
simpler to go back to a void* I think.  (I'll wait to push to coverity
until all of these code changes happen.)

On Thu, Dec 29, 2016 at 10:07 PM, Steven Yi  wrote:
> I'm not sure if the data needs to be kept in Csound's global vars now,
> but regardless, I rebuilt the latest from GIT and things look good
> here to run multiple times here on Windows with Blue.  It looks good
> to go for me, but I'll push to Coverity to see if it finds anything
> now.
>
> Thanks!
> steven
>
> On Thu, Dec 29, 2016 at 9:55 PM, Michael Gogins
>  wrote:
>> I have done to the experiment. The behavior is the same on Windows:
>> global variables in shared libraries are created as fresh copies in
>> each module that is loaded.
>>
>> Accordingly, I changed the code in signalflowgraph.cpp. I retained
>> your mutex creation and locking/unlocking code, but I query the global
>> variables only on module initializaton, and set them to global
>> variables, which simplifies the code and probably gives slightly
>> better performance.
>>
>> Best,
>> Mike
>>
>>
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Thu, Dec 29, 2016 at 8:39 PM, Michael Gogins
>>  wrote:
>>> I will find if it is the case on WIndows by experiment.
>>>
>>> Best,
>>> Mike
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Thu, Dec 29, 2016 at 8:33 PM, Steven Yi  wrote:
>>>> Thanks Michael for researching that; is this the case for all OS's?
>>>> I'll test on Windows and Linux with Blue once there are code changes
>>>> to test.
>>>>
>>>> On Thu, Dec 29, 2016 at 7:00 PM, Michael Gogins
>>>>  wrote:
>>>>> My code for signalflowgraph.cpp (and in other places) is based on a
>>>>> false assumption about static variables in a process.
>>>>>
>>>>> I know that when a process loads a shared library, the operating
>>>>> system creates a copy of all static variables for the code in that
>>>>> shared library.
>>>>>
>>>>> I assumed this meant that if the same process loads the same shared
>>>>> library multiple times, just one copy of the static variables is used.
>>>>>
>>>>> I have now read and proved by testing that in fact, the operating
>>>>> system creates a new copy of static variables in a module each time
>>>>> that module is loaded, even if it is re-loaded into the same process.
>>>>>
>>>>> I will change my code to reflect this.
>>>>>
>>>>> There isn't, therefore, actually any problem with multiple instances
>>>>> of Csound in the same process.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> -----------------------------------------------------
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://michaelgogins.tumblr.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>>
>>>>> On Thu, Dec 29, 2016 at 3:12 PM, Michael Gogins
>>>>>  wrote:
>>>>>> I understand about the memory leak, but my view was that this is an
>>>>>> acceptable tradeoff: Either there is a small memory leak but multiple
>>>>>> instances of Csound can run in the same process using the signal
>>>>>> flowgraph opcodes, as with Cabbage plugins or CsoundVST in a digital
>>>>>> audio workstation, or the signal flow graph opcodes cannot be used in
>>>>>> a DAW but there is no memory leak from these mutexes.
>>>>>>
>>>>>> However, a better option is to use an atexit handler for these global
>>>>>> statics. At any rate, I will debug this and find out what is really
>>>>>> going on.
>>>>>>
>>>>>> The scale of memory growth reported in issue 722 is vastly greater
>>>>>> than that reported by valgrind. Does anybody have an answer for that?
>>>>>> Does it occur only with soundfile output or only for real-time audio
>>>>>> output?
>>>>>>
>>>>>> In issue 722,do you mean the jack driver for command-line options, or
>>>>>> the Jacko opcodes?
>>>>>>
>>>>>> Regards,
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------
>>>>>> Michael Gogins
>>>>>> Irreducible Productions
>>>>>> http://michaelgogins.tumblr.com
>>>>>> Michael dot Gogins at gmail dot com
>>>>>>
>>>>>>
>>>>>> On Thu, Dec 29, 2016 at 12:45 PM, Victor Lazzarini
>>>>>>  wrote:
>>>>>>> They needed to be cleared because they were causing memory leaks every time
>>>>>>> Csound is reset. I chased all of these leaks and there are none now (at least on OSX/Linux).
>>>>>>>
>>>>>>> https://github.com/csound/csound/issues/722
>>>>>>>
>>>>>>> Even if we are not using the opcodes, the loading and unloading process will leak memory.
>>>>>>> ========================
>>>>>>> Prof. Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952
>>>>>>>
>>>>>>>> On 29 Dec 2016, at 17:03, Michael Gogins  wrote:
>>>>>>>>
>>>>>>>> Got it, thanks.
>>>>>>>>
>>>>>>>> Yes, that's a problem. The mutexes are supposed to protect the data
>>>>>>>> tables from data races or overwrites between different instances of
>>>>>>>> Csound, but of course if the module is destroyed by one instance while
>>>>>>>> being used by another instance, the current code will not work. To
>>>>>>>> precise, the current code is fine for different instances of Csound
>>>>>>>> that run in different processes, but if there are different instances
>>>>>>>> of Csound in the same process, then there is a problem.
>>>>>>>>
>>>>>>>> The best solution is just to leave these variables alone. Don't try to
>>>>>>>> delete or zero them. If you think they really need to be deleted, it
>>>>>>>> should not be done in csoundReset but in an atexit handler. For a
>>>>>>>> process, they'll just go away when the process exits. For different
>>>>>>>> instances of Csound in the same process, these mutexes should in fact
>>>>>>>> be global to the process.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> -----------------------------------------------------
>>>>>>>> Michael Gogins
>>>>>>>> Irreducible Productions
>>>>>>>> http://michaelgogins.tumblr.com
>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Dec 29, 2016 at 11:43 AM, Steven Yi  wrote:
>>>>>>>>> I think John and I are referring to these uses of static mutex locks:
>>>>>>>>>
>>>>>>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L138-L139
>>>>>>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>>>>>>>> https://github.com/csound/csound/blob/develop/Opcodes/signalflowgraph.cpp#L1813-L1818
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Dec 29, 2016 at 11:33 AM, Michael Gogins
>>>>>>>>>  wrote:
>>>>>>>>>> If you are talking about the signal flow graph opcodes, the code is
>>>>>>>>>> re-entrant. There are indeed static tables of objects, but those
>>>>>>>>>> objects are mapped by Csound instance as well as object instance.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Mike
>>>>>>>>>>
>>>>>>>>>> -----------------------------------------------------
>>>>>>>>>> Michael Gogins
>>>>>>>>>> Irreducible Productions
>>>>>>>>>> http://michaelgogins.tumblr.com
>>>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Dec 29, 2016 at 10:40 AM, jpff  wrote:
>>>>>>>>>>> Looks as if flowgraph uses data statics which we removed throughout csound
>>>>>>>>>>> to make it re-entrant.   So it is unsafe
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, 29 Dec 2016, Steven Yi wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Would there be problems if multiple Csound instances are created?
>>>>>>>>>>>> (thinking of
>>>>>>>>>>>> how Rory uses Csound instances in Cabbage)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Dec 29, 2016, 5:11 AM Victor Lazzarini 
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>      This should be ok, since it happens on reset. I had to add those
>>>>>>>>>>>>      lines because a leak was reported on csoundReset().
>>>>>>>>>>>>
>>>>>>>>>>>>      Victor Lazzarini
>>>>>>>>>>>>      Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>>>>>>      Maynooth University
>>>>>>>>>>>>      Ireland
>>>>>>>>>>>>
>>>>>>>>>>>>> On 29 Dec 2016, at 02:31, Steven Yi  wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> After running a git bisect session, the commit that was found
>>>>>>>>>>>>      where
>>>>>>>>>>>>> the problem started is this one:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> https://github.com/csound/csound/commit/60593c7807cd4d0931254843db2421da6d4dc
>>>>>>>>>>>>      652
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've pushed a fix at:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> https://github.com/csound/csound/commit/a02db25c3d2bc3ab0d89d4f9a6487bf325d84
>>>>>>>>>>>>      46e
>>>>>>>>>>>>>
>>>>>>>>>>>>> The change seems to make things work as exepcted.  Victor: Could
>>>>>>>>>>>>      you
>>>>>>>>>>>>> review this fix? I think because the values were only freed but
>>>>>>>>>>>>      not
>>>>>>>>>>>>> zeroed, it caused problems on second and third runs and resulted
>>>>>>>>>>>>      in an
>>>>>>>>>>>>> attempt to free a value that was freed before.  However, I'm
>>>>>>>>>>>>      concerned
>>>>>>>>>>>>> about this code being thread-safe, even before my fix.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Dec 28, 2016 at 7:29 PM, Steven Yi 
>>>>>>>>>>>>      wrote:
>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Just FYI, Menno reported on the Blue list that there's a
>>>>>>>>>>>>      problem with
>>>>>>>>>>>>>> Csound.  WIth the latest from GIT, Blue crashes always after
>>>>>>>>>>>>      the 3rd
>>>>>>>>>>>>>> time running Csound (via API).  The email thread has more
>>>>>>>>>>>>      information
>>>>>>>>>>>>>> here:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://sourceforge.net/p/bluemusic/mailman/message/35569588/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've been able to reproduce the problem here.  Rewinding to
>>>>>>>>>>>>      commit
>>>>>>>>>>>>>> 2e4e390dbfb9af82090cb45f12f8eadd2f78fe98 from October 11th, I
>>>>>>>>>>>>      can run
>>>>>>>>>>>>>> Csound multiple times within Blue without problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't have much more information yet beside that I see that
>>>>>>>>>>>>      the
>>>>>>>>>>>>>> crash happens restting Csound.  I'll take a look at using git
>>>>>>>>>>>>      bisect
>>>>>>>>>>>>>> to see if I can find the problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> steven
>>>>>>>>>>>>
>>>>>>>>>>>>