Cabbage Logo
Back to Cabbage Site

Strangeness in the output console when the performance ends

#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.

#61

Exactly what’s the error you have? You have a log of the problem?

P.S.: what does Cabbage when you click on the STOP button? I cannot find where is the code that makes the Csound performance stop after you click that button…

#62

vcpkg is not installing libsndfile. It works fine for me at home, but my not on my work PC. Strange. I will look into it again tomorrow.

Csound stops because I suspend processing(see below), but it is not released. It’s get destroyed before a compile (if it’s a valid object). I don’t destroy the node when a user hits stop because I wish to maintain the graph connections. I can take a look tomorrow and see how destroying Csound when a user hits stop works. I’ll just have to keep a record of the node connections so the patch remains in tact.

#63

Yes, I wanted to try that…

#64

UPDATE: It’s definitely not a Cabbage problem.

I just made a csd that goes in crash in both CsoundQT and from command line too… (segmentation violation)

#65

Nice work. Now we can bring it to the attention of the Csound devs. Great.

[edit] I see you already have! You move fast.

#66

Yes, I just sent a mail to the [Csnd-dev] list. I hope this can be solved soon… :slight_smile:

#67

I might revert that code back to how it was in this case.

#68

Yes, you should. Now I’m sure that those added lines are useless regards this matter. It could be nice if Cabbage could “intercept” a segmentation violation caused by Csound (during its performance) so that in these cases it doesn’t have to exit forcefully.

#69

I wish that was possible, but I can’t intercept segmentation faults like this. When they happen Cabbage get taken down. I can’t do anything about it. As I mentioned before, the only workaround would be to launch Csound in its own separate process that runs alongside Cabbage. This will lead to other issues. I’m open to suggestion in how to get this to work, but I don’t think there is an easy way, as audio data has to be passed between Csound and Cabbage.

#70

I’m a bit rusty on the matter, but do you think is it possible in C++ to catch a segfault exception?

#71

I think it is possible catch it, but even if you do I don’t think it can save the host from crashing. See this post:


I guess it might still be worth a try?

#72

Btw, I should also mention that CabbageLite is a pretty useful tool for testing stuff. It doesn’t have the same overhead as the Cabbage IDE so it can often be easier to debug issues there.

#73

Yes, I think that what they say in that post generally speaking is right… If you allow your code to continue the execution there could be other memory leaks problems, because the Csound code that goes in segfault break its normal execution and then maybe it cannot do anymore all its deallocation stuff. So, maybe Cabbage could continue to work, but then the ram potentially would grow bigger at each rerun of the csd.

#74

So it kind of leaves us stuck in limbo? Doesn’t seem to be much that can be done about it, apart from helping the Csound devs catch the underlying issues :wink: