Some more comments on the previous matters.
vamp-plugin-tester(2548,0xa03f4540) malloc: *** error for object 0x4001e0: pointer being freed was not allocatedAfter which the plug-in still seems to have gone on with its work... Is that normal? is this a problem with the plug-in, or with the plug-in tester?
*** set a breakpoint in malloc_error_break to debug
This is a problem with the plugin, but one that the tester can't detect -- the message probably comes from a debug version of the C library which the plugin is linked with. This is the sort of thing that Valgrind would detect and show a more thorough explanation of, if you could get it to run satisfactorily. It means just what it says -- at some point you are freeing a pointer that you didn't allocate -- but unfortunately that on its own isn't necessarily going to help you much to find the cause. Review all places where a pointer may be freed or deleted.
I actually had a question related to this problem.
Let's say I have an array in my plug-in, which is also the output feature. For instance, say in the power spectrum example (http://www.vamp-plugins.org/code-doc/PowerSpectrum_8cpp-source.html
), instead of returning the values directly in the feature set (with a push_back, at line 00157), you define an array in the class:
and then initialize it, work on it in the process method:
size_t n = m_blockSize / 2 + 1;
m_powerSpectrum = new float[n];
... // filling in the array and
... // after processing, putting the result in the desired feature set
Since this array has been allocated, I guess I should free that memory at some stage... but when would be the best time to do so? It seems that freeing it at the end of process makes the plug-in crash, and some of the errors I talked before might come from freeing these arrays in the destructor, or in the reset method.
Does this make sense, or should I look for some other potential reason?
I tried again with valgrind, but I seem to ask too much memory (by the way, is that something bad for the plug-in, if I want more memory than valgrind can use? I mean, should I expect problems after, when using the plug-in in SV?).
Anyway, it works fine for Linux and Mac, and now, under Windows, with a cross compiled version, when I launch SV, it tells me:
This application has requested the Runtime to terminate it in an unusual way. Please contact ...Trying with the provided windows vamp-plugin-tester, I get the same error, and just before, something that goes:
terminate called after throwing an instance of 'std::bad_alloc'
That error means that operator new() failed -- you requested allocation of more memory than was available. That may mean you have tried to allocate far more memory than you actually needed for some reason, or that you simply don't have enough memory -- or it might indicate a more subtle programming error such as unsigned integer underflow. For example, something like
float *f = new float[n - m];
may cause that exception to be thrown if either n or m is unsigned and n is smaller than m.
See if you can run it under a debugger and get a stack trace for the crash -- the innermost stack frames should show where the exception was thrown.
It would seem that the error was caused by some unlucky combinations, at the plug-in first call. That seems related to a problem I talked about some time ago, with the initialisation of the parameters.
In order to provide the binNames, in the getOutputDescriptors method, I was filling-in a vector of strings, for which I assumed the size could not exceed 10 characters. At the first call, however, the values of blockSize and inputSampleRate make the strings a bit longer. Since I was using them to fill my array of char, I was basically writing a bit everywhere, which seemed not to worry SV under Linux or Mac, but which caused SV under Windows to crash right away. Does this sound like a normal behavior for SV, under these different OS's?
I m still running some tests to check whether some more bugs appear... I must admit I have gone through some strange crashes, like some sets of parameters that (randomly) led to unexpected crashes. Hard to trace back... Does the plug-in tester also test several parameter configurations? That would be an interesting feature.