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:
+--> subinstr "Instr B"
+--> "Instr B" calls an opcode that uses
auxfd.c facilities (for example: linseg)
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.