Hi All,

I've been working with Blue and CS6 the past few days and getting
frequent crashes.  I've been using the API6Test.java that is pasted in
below.  I'm not positive what's exactly going on, but my analysis so
far is:

1. Csound crashes when ~Csound in the C++ class is called. In ~Csound
(this is from include/csound.hpp), this calls csoundDestroy.

2. The way I'm seeing things happening are that the SWIG generated
code calls delete on the Csound C++ object in the Java finalize()
method for Csound.java.  Now, in Java, finalizers are called when the
object has no references and is being freed up by the garbage
collector, which is indeterminant as to when the GC will actually free
the object.

3. I believe the problem is caused by the change in code where we
store csound->self and set that to NULL.  For some reason it is
getting set to NULL or getting called twice or something.  It seems
like something is flubbing things so by the time csoundDestroy is
called it causes a memory related crash.

4. If I modify the test code to call cs.delete() explicitly, when the
finalizer runs, the code there checks if there is still a SWIG cptr
and if not, then it won't run the delete related code.  That doesn't
seem to cause a crash.  I don't know why that would be alright when
called manually but not from the finalizer.

I'm about to test a change in Blue to call cs.delete().  I'd like to
figure out why this is all crashing.  I suppose this *might* affect
Android as well, though I have not tested much on Android recently and
don't know if there have been issues there or not regarding crashes.

Thanks,
steven






import csnd6.*;

class API6Test {

  public static void main(String args[]) {

    csnd6.csoundInitialize(csnd6.CSOUNDINIT_NO_SIGNAL_HANDLER |
csnd6.CSOUNDINIT_NO_ATEXIT);

    for(int i = 0; i < 20; i++) {
        System.out.println("\nTest " + i);

        Csound cs = new Csound();
        CsoundCallbackWrapper wrapper = new CsoundCallbackWrapper(cs) {

        };
        wrapper.SetMessageCallback();
        cs.Start();

        for(int j = 0; j < 10; j++) {
          cs.PerformKsmps();
        }

        cs.Stop();
 //       cs.Cleanup();
        cs.SetMessageCallback(null);
 //       cs.Reset();
//        cs.delete();
        //cs = null;
        System.gc();
    }

  }

}

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi All,

I have done further research and determined that the problem was not
really being fixed by explicit calling of delete. What I did find
though is that the code for csoundCreate and the usage of csound->self
was, IMO, in error.

What I did was set break points on csoundCreate and csoundDestroy.  In
the test java file, everytime it hit csoundCreate, the value of
csound->self was set to the same address every time for every instance
created. This makes sense in my head, as we are setting it to the
address of the CSOUND* csound that is the local pointer for the
function. I would imagine that the stack there could point to the same
address between csoundCreate runs. In the test code I was running,
csoundCreate was called 3 times before a csoundDestroy was called. It
looks to me that destroy was called from another thread while a
csoundCreate call was going on.  The destroy deleted the memory at the
*csound in csoundCreate since it was all pointing to the same mem
address.

I don't know how API's that NULL out pointers are generally designed,
but I suspect that they would usually pass in a pointer to the create
function and that would get assigned to the struct->self.  I.e., if
csoundCreate was like:

int csoundCreate(CSOUND* csound, void* hostData)

Then we could use the pointer that was passed in to assign to
csound->self and it would potentially unique.  As it is now, it's a
problem, so I've commented the code out.

I think we should just get rid of the ->self code due to the above
problems.  If you have comments or could point out problems with my
analysis, please do reply.

Thanks!
steven

On Sun, Dec 1, 2013 at 8:45 PM, Steven Yi  wrote:
> Hi All,
>
> I've been working with Blue and CS6 the past few days and getting
> frequent crashes.  I've been using the API6Test.java that is pasted in
> below.  I'm not positive what's exactly going on, but my analysis so
> far is:
>
> 1. Csound crashes when ~Csound in the C++ class is called. In ~Csound
> (this is from include/csound.hpp), this calls csoundDestroy.
>
> 2. The way I'm seeing things happening are that the SWIG generated
> code calls delete on the Csound C++ object in the Java finalize()
> method for Csound.java.  Now, in Java, finalizers are called when the
> object has no references and is being freed up by the garbage
> collector, which is indeterminant as to when the GC will actually free
> the object.
>
> 3. I believe the problem is caused by the change in code where we
> store csound->self and set that to NULL.  For some reason it is
> getting set to NULL or getting called twice or something.  It seems
> like something is flubbing things so by the time csoundDestroy is
> called it causes a memory related crash.
>
> 4. If I modify the test code to call cs.delete() explicitly, when the
> finalizer runs, the code there checks if there is still a SWIG cptr
> and if not, then it won't run the delete related code.  That doesn't
> seem to cause a crash.  I don't know why that would be alright when
> called manually but not from the finalizer.
>
> I'm about to test a change in Blue to call cs.delete().  I'd like to
> figure out why this is all crashing.  I suppose this *might* affect
> Android as well, though I have not tested much on Android recently and
> don't know if there have been issues there or not regarding crashes.
>
> Thanks,
> steven
>
>
>
>
>
>
> import csnd6.*;
>
> class API6Test {
>
>   public static void main(String args[]) {
>
>     csnd6.csoundInitialize(csnd6.CSOUNDINIT_NO_SIGNAL_HANDLER |
> csnd6.CSOUNDINIT_NO_ATEXIT);
>
>     for(int i = 0; i < 20; i++) {
>         System.out.println("\nTest " + i);
>
>         Csound cs = new Csound();
>         CsoundCallbackWrapper wrapper = new CsoundCallbackWrapper(cs) {
>
>         };
>         wrapper.SetMessageCallback();
>         cs.Start();
>
>         for(int j = 0; j < 10; j++) {
>           cs.PerformKsmps();
>         }
>
>         cs.Stop();
>  //       cs.Cleanup();
>         cs.SetMessageCallback(null);
>  //       cs.Reset();
> //        cs.delete();
>         //cs = null;
>         System.gc();
>     }
>
>   }
>
> }

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hello Steven,

Just noticed your post today.

I have had the same problem using the JDK and on Android. The workaround I
use is to keep hold of a AndroidCsound on Android and csnd6.Csound using the
JDK, and reuse that instance, creating new ones causes crashes, maybe when
the previous one is being destroyed(?).

When the performksmps is complete I call:

		csound.Stop();
		csound.Cleanup();	    
		csound.Reset();

And reuse the sound instance in the next performance.

On android I noticed that calling ((AndroidCsound)
csound).setOpenSlCallbacks(); in an app that creates multiple instances of
sound, eventually crashes (e.g.: csdplayer). Not calling
setOpenSlCallbacks() though means there is no sound produced.

I hope this is of some help.

All the best,

Jacques





--
View this message in context: http://csound.1045644.n5.nabble.com/Java-Crashes-tp5730435p5730618.html
Sent from the Csound - Dev mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Jacques,

I was thinking that the Android code maybe needs to be checked after
these recent discoveries. I don't know if there is a way to get Swig
to ensure that the Java interface correctly manages pointer ownership
and reference counts. (There's some things about pointer ownership in
the manual but I haven't had the time to figure it out yet; maybe
someone else might have some ideas here).

For the crashes, do you have the signalflow graph opcode library in
use?  I'm curious as that was a cause of crashes here on the desktop,
but Michael has fixed that and I don't know if that is an issue on
Android yet. If that's not an issue, do you have an example project
that demonstrates the problem?

Thanks!
steven

On Fri, Dec 6, 2013 at 6:09 AM, Jacques  wrote:
> Hello Steven,
>
> Just noticed your post today.
>
> I have had the same problem using the JDK and on Android. The workaround I
> use is to keep hold of a AndroidCsound on Android and csnd6.Csound using the
> JDK, and reuse that instance, creating new ones causes crashes, maybe when
> the previous one is being destroyed(?).
>
> When the performksmps is complete I call:
>
>                 csound.Stop();
>                 csound.Cleanup();
>                 csound.Reset();
>
> And reuse the sound instance in the next performance.
>
> On android I noticed that calling ((AndroidCsound)
> csound).setOpenSlCallbacks(); in an app that creates multiple instances of
> sound, eventually crashes (e.g.: csdplayer). Not calling
> setOpenSlCallbacks() though means there is no sound produced.
>
> I hope this is of some help.
>
> All the best,
>
> Jacques
>
>
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Java-Crashes-tp5730435p5730618.html
> Sent from the Csound - Dev mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hello Steven,

After further investigation, I have found the problem in my Android code.
CSound crashes if the CSound environment is initialised before each run of a
csd, so creating a new instance of Csound before each run of a csd does not
cause problems.

Below is the method I use to initialise the CSound environment, which should
not be called many times:

	private void initCSoundEnv(Context ctx) {
		/**
		 * Initialise CSound env & load libraries
		 */
		Log.d(tag, "************** Init CSound env");
		String OPCODE6DIR = ctx.getApplicationInfo().nativeLibraryDir;
		SharedPreferences sharedPreferences =
PreferenceManager.getDefaultSharedPreferences(ctx);
		OPCODE6DIR = sharedPreferences.getString("OPCODE6DIR", OPCODE6DIR);
		csnd6.csndJNI.csoundSetGlobalEnv("OPCODE6DIR", OPCODE6DIR);
		File file = new File(OPCODE6DIR);
		File[] files = file.listFiles();
		Log.d(tag, "Loading Csound plugins...");
		for (int i = 0; i < files.length; i++) {
			String pluginPath = files[i].getAbsoluteFile()
					.toString();
			try {
				Log.d(tag, pluginPath);
				System.load(pluginPath);
			} catch (Throwable e) {
				Log.e(tag,"Error loading plugin " + pluginPath, e);
			}
		}
		// Evidently, this has to be set before
		// the very first Csound object is created.
		csnd6.csndJNI.csoundSetGlobalEnv("OPCODE6DIR", OPCODE6DIR);
	}

The libraries present in the project are: 
- libfluidOpcodes.so
- libLuaCsound.so
- libsignalflowgraph.so
- libstdutil.so

Plus those in CSoundAndroid:
- libcsoundandroid.so
- libgnustl_shared.so
- libsndfile.so

I have found it tough to know which opcode shared libraries to include if I
want to use libfluidOpcodes.so, I found that putting in all the libraries
listed works, trying to leave out shared libraries that seemed unrelated (to
me) invariably caused the fluid engine to be unrecognised by CSound.

Attached is an android project  TestAndroidCsound.zip
  
that creates a temporary csd and plays it, 100 times.

All the best,

Jacques




--
View this message in context: http://csound.1045644.n5.nabble.com/Java-Crashes-tp5730435p5730629.html
Sent from the Csound - Dev mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Jacques,

I haven't had a chance to try your project, but could you maybe try this build:

http://www.kunstmusik.com/csound-android-6.01.0.zip

This is built with Android NDK r9b, and is the latest from GIT develop
branch.  I'm betting that the crash problems were related to the ones
I had for Blue and that the recent changes will fix it.

Let me know how it goes!
steven

On Sat, Dec 7, 2013 at 7:06 AM, Jacques  wrote:
> Hello Steven,
>
> After further investigation, I have found the problem in my Android code.
> CSound crashes if the CSound environment is initialised before each run of a
> csd, so creating a new instance of Csound before each run of a csd does not
> cause problems.
>
> Below is the method I use to initialise the CSound environment, which should
> not be called many times:
>
>         private void initCSoundEnv(Context ctx) {
>                 /**
>                  * Initialise CSound env & load libraries
>                  */
>                 Log.d(tag, "************** Init CSound env");
>                 String OPCODE6DIR = ctx.getApplicationInfo().nativeLibraryDir;
>                 SharedPreferences sharedPreferences =
> PreferenceManager.getDefaultSharedPreferences(ctx);
>                 OPCODE6DIR = sharedPreferences.getString("OPCODE6DIR", OPCODE6DIR);
>                 csnd6.csndJNI.csoundSetGlobalEnv("OPCODE6DIR", OPCODE6DIR);
>                 File file = new File(OPCODE6DIR);
>                 File[] files = file.listFiles();
>                 Log.d(tag, "Loading Csound plugins...");
>                 for (int i = 0; i < files.length; i++) {
>                         String pluginPath = files[i].getAbsoluteFile()
>                                         .toString();
>                         try {
>                                 Log.d(tag, pluginPath);
>                                 System.load(pluginPath);
>                         } catch (Throwable e) {
>                                 Log.e(tag,"Error loading plugin " + pluginPath, e);
>                         }
>                 }
>                 // Evidently, this has to be set before
>                 // the very first Csound object is created.
>                 csnd6.csndJNI.csoundSetGlobalEnv("OPCODE6DIR", OPCODE6DIR);
>         }
>
> The libraries present in the project are:
> - libfluidOpcodes.so
> - libLuaCsound.so
> - libsignalflowgraph.so
> - libstdutil.so
>
> Plus those in CSoundAndroid:
> - libcsoundandroid.so
> - libgnustl_shared.so
> - libsndfile.so
>
> I have found it tough to know which opcode shared libraries to include if I
> want to use libfluidOpcodes.so, I found that putting in all the libraries
> listed works, trying to leave out shared libraries that seemed unrelated (to
> me) invariably caused the fluid engine to be unrecognised by CSound.
>
> Attached is an android project  TestAndroidCsound.zip
> 
> that creates a temporary csd and plays it, 100 times.
>
> All the best,
>
> Jacques
>
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Java-Crashes-tp5730435p5730629.html
> Sent from the Csound - Dev mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hello Steven,

Thanks for the update. 

I downloaded your new build for Android and tested it in my projects. Works
great! Initialising the environment 100 times no longer causes crashes. 

Nice pre-xmas present, thanks!

All the best,

Jacques



--
View this message in context: http://csound.1045644.n5.nabble.com/Java-Crashes-tp5730435p5730685.html
Sent from the Csound - Dev mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Glad to hear that's solved the problem, enjoy!

steven

On Tue, Dec 10, 2013 at 5:02 AM, Jacques  wrote:
> Hello Steven,
>
> Thanks for the update.
>
> I downloaded your new build for Android and tested it in my projects. Works
> great! Initialising the environment 100 times no longer causes crashes.
>
> Nice pre-xmas present, thanks!
>
> All the best,
>
> Jacques
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Java-Crashes-tp5730435p5730685.html
> Sent from the Csound - Dev mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net