Development Topics > Plugin Development
About debugging a plug-in
cannam:
--- Quote from: jean-louis on January 10, 2011, 13:22:49 ---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:
--- Code: ---float *m_powerSpectrum;
--- End code ---
and then initialize it, work on it in the process method:
--- Code: ---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
--- End code ---
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?
--- End quote ---
If m_powerSpectrum is a member of the plugin class and is allocated in the initialise method, then it should be freed in the destructor.
Note that, in this case, it should also be assigned to zero in the constructor, or else the destructor will crash if initialise is never called -- it is OK to delete[] a null pointer, unlike free() in C; but it's never OK to delete a pointer that has been declared but never initialised at all.
In the reset method, then, you could either delete and reallocate the pointer, or more likely you could reset the contents of its array to zero (since its intended size would be unchanged), or even leave them unchanged if their values don't matter.
If powerSpectrum was a variable allocated in process() and then used only in process(), then it should be deleted before process() returned -- but you'd obviously have to be sure to have copied all of the data you needed out of it before deleting it.
--- Quote from: jean-louis on January 10, 2011, 13:22:49 ---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?
--- End quote ---
It sounds like you just got lucky under Linux and OS/X. Possibly it would have crashed later if the data had been deleted.
Generally it's a very bad idea to use fixed-size string arrays for data that you can't be totally confident of the length of -- this is a big cause of a very common class of security-related buffer overflow errors and, while that's maybe not going to be a practical issue in this code, it means it's something well worth learning to avoid in general.
Also, if your "strings" are actually char pointers allocated using new char[] or even malloc(), then it's a bad idea to put them into a vector because the vector will be unable to delete them and recover the memory when its destructor is called (as they are not objects with destructors themselves).
Generally, if you want a vector of strings in C++, you should always use a vector of std::string. If you want to "print" float or int values into the strings, consider using a std::ostringstream to build them.
I hope I'm not barking up the wrong tree here -- I'm making some rather wild guesses about what your data structure actually is, so my apologies if I've misunderstood!
Chris
Navigation
[0] Message Index
[*] Previous page
Go to full version