Cabbage Logo
Back to Cabbage Site

Strangeness in the output console when the performance ends

#41

That’s odd. I can’t see how this would have any affect on things. The editor tab has nothing to do with the instance of Csound that is running. Things like this always stink of memory issues. Does waiting some time before hitting play make any difference?

#42

No, I just tried to wait more then ten seconds before clicking STOP and then I waited other 10 seconds before rePLAY too, but it crashes…

For testing I would like to make Cabbage close and reopen the csd file every time you click on the STOP button (simulating the click on the little red ‘X’ in the toolbar). If this could avoid to make Cabbage crash the second time I run my csd I would be very happy… It would be difficult to make such a mod? What function I should change in the Cabbage source code?

#43

You can add the following code to the line marked below:

const String currentFile = getCurrentCsdFile().getFullPathName();
editorAndConsole[currentFileIndex]->toFront (true);
closeDocument();
openFile (currentFile);
#44

I tried, but then, when you save and play the csd, you cannot stop Csound because the STOP button becomes PLAY immediately.

#45

Ok, I made some changes and now it doesn’t crash anymore.

Change the following lines:

with these:

 if (recompile == true && getCurrentCsdFile().hasFileExtension ((".csd")))
 {
	// TO AVOID SOME INSTABILITY PROBLEMS IN REPLAYING THE SAME FILE:
	// --------------------------------------------------------------
	// CLOSE THE OPEN WINDOWS RELATED TO THIS CSD:
	int32 node = fileTabs[currentFileIndex]->uniqueFileId;
	audioGraph->closeCurrentlyOpenWindowsFor(node);
	// SAVE THE CURRENT FILENAME BEFORE CLOSING THE DOCUMENT:
	const String currentFile = getCurrentCsdFile().getFullPathName();
	closeDocument();
	// REOPEN THE CLOSED FILE:
	openFile(currentFile);
	// --------------------------------------------------------------

	runCsoundForNode (getCurrentCsdFile().getFullPathName());
        //fileTabs[currentFileIndex]->getPlayButton().setToggleState (true, dontSendNotification);
 }

and to me it doesn’t crash anymore.

#46

Can you try loading a few instruments and seeing if it still works Ok. Also, can you view the Cabbage patcher and see if all connections are still valid? I guess I can add this mod to the source. It shouldn’t really have any negative effects.

#47

The problem with the above mod is that, strangely, now the memory keeps on growing each time you play the same csd file. To be honest, it happens without these mods too, but in a much lesser way. Maybe making a closeDocument() followed by an openFile(…), just before the runCsoundForNode, could do some redundant memory allocations…

#48

Now happens another strange thing: when I stop and play the same csd file, in the Cabbage patcher it’s added and connected a new plugin, clone of the first one… Maybe this is related to the redundant memory allocation…

If I start and stop 3 times I will have:

patcher.jpg600×629 23.4 KB

#49

Good, now we’re getting somewhere. I updated the audio graph stuff a few months back but never really had a chance to push it to the limit. Multiple duplicates of nodes could well be an issue. The don’t appear graphically in the public release, but they might still be lurking somewhere in the graph. I will take a look as soon as I get a chance. Thanks.

#50

From what I understand, with my changes I have no more crashes because now I create a new audiograph instance (and maybe a new Csound instance?) each time I stop & play the csd. So, I’ve not solved the problem but I just delayed it to the exit of Cabbage. In fact, with my changes, when you exit from Cabbage I receive the exception error in the VS debugger just before Cabbage closes itself, when it tries to close all the open instances of the audiograph.
It could be good for me, if it weren’t for those multiple patches that make the memory grows a little each time you stop&start the csd.

Another thing I noticed is that with my changes, the delete of a patch in the cabbage patcher won’t work anymore.

#51

Sorry I haven’t got around to looking into this yet. I’m up to my eyes at work at the moment. I will look at it soon.

#52

Don’t worry, take your time. :wink:

#53

I’ve pushed a fix through now to the master branch. I’m happy to go with this change for now. We can give it a test and see if it’s Ok. The problem in the last fix was that it created a new unique nodeId on each run, rather than using the previous ID. Should work fine now. I was rather hoping it was something more serious as it might have helped explain another issue I’m seeing on random Windows machines.

#54

Yes, it makes sense. Now the patcher works but, unfortunately, my code is back to crash after the second start. The error is always the same: an access violation (in that “auxfd.c” file of the Csound engine).

#55

Hmm. I’m still concerned that we’re chasing a pink elephant here. Let me try something. I’ll get back to you…

[edit] Can you try the latest master branch? The Csound deconstructor should be called before the node is removed from the graph. I’m not sure it will help, but it can’t hurt…

#56

You needn’t bother, it also fails. I’m not sure how best to proceed here. The crash looks like it’s being caused by Csound. I’ll see if I can set up a Windows build of Csound here. We also have to keep in mind that this is local to Windows. I can’t recreate the crash on Linux or OSX…

#57

I’m having some issues installing Csound on this machine. The bat files responsible for getting everything are not finding libsndfile for some reason. Did you have the same issue when you built it?

#58

No, I had some problems with some pathnames that I had to add to the PATH environment variable for the commandline. Have you generated all the necessary dependencies first? There is a bat file for that: “downloadDependencies.bat”.

#59

That’s strange…

Anyway, I did some research on the Csound “auxfd.c” source file (the file where the debugger gives the exception). It has various utility functions to dynamically allocate memory and files. It is not mandatory to use those internal functions, but many Csound opcodes use them because, theoretically, they should prevent the developer of native opcodes from running in memory leak problems. For example, linseg, transeg, and many other opcodes use those functions to allocate memory.

Let’s suppose in your native opcode you need to dynamically allocate an array of “size” bytes, where “size” depends from an input parameter of the opcode. Then with the utilities provided in auxfd.c you can do something like this:

csound->AuxAlloc(csound, size, &p->auxch);

after that, your data becomes accessible from the pointer “p->auxch.auxp”, and you do not have to worry to release it, because Csound should take care of that for you.

Now, back to our problem, to reproduce the crash, your csd should be made so that you have the following sequence:

"Instr A"
   |
   +--> subinstr "Instr B" 
		    |
		    +--> "Instr B" calls an opcode that uses 
			  auxfd.c facilities (for example: linseg) 
				||
			        \/
                             Csound CRASHES
			    (access violation) 
				||
				\/
			     Cabbage CRASHES

The crash occurs the 2nd time you start the problematic csd file in Cabbage (but only if you play 10-15 notes in polyphony before STOP & rePLAY).

What happens is that, the 2nd time you press PLAY in Cabbage, the “auxchfree” routine in the Csound “auxfd.c” file tries to access to the data in “ip->auxchp->auxp” to release its allocated memory, but it cannot access to that memory because (I suppose) it has been already deallocated by some other function (this could happen when you press the STOP button in Cabbage?).

Now, you would think that there could be some problem in the Csound code related to the auxfd functions, but the strange thing is that in CsoundQT that same csd, in the same situation, doesn’t crash!

I tried to debug the relevant Csound code, but I wasn’t able to find an obvious memory leak.

#60

As I said before CsoundQT used Csound’s IO drivers, so it’s not really the same. And I think it use a different threading mechanism. There are some profiling tools in VS that might help. If I can get a build going I will try them. The problem at the moment for me if that the downloads script is not installing libsndfile. So cmake cannot find it.