Development Topics > Plugin Development
About debugging a plug-in
jean-louis:
Since this is also about the same plug-in, and running vamp-plugin-tester, I post a little remark in this topic (although some digressions have already be done there...)
I just ran vamp-plugin-tester on my plug-in, and obtain a nice
--- Code: ---vamp-plugin-tester: All tests succeeded for this plugin
--- End code ---
However, checking a bit further up, I noticed this:
--- Code: --- -- Performing test: B2 Invalid or dubious timestamp usage
vamp-plugin-tester(2548,0xa03f4540) malloc: *** error for object 0x90ce18ae: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
vamp-plugin-tester(2548,0xa03f4540) malloc: *** error for object 0x4001e0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
--- End code ---
After 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?
Cheers!
jean-louis:
I know I get to talk a bit too much about that plug-in... I ll soon send an announcement for it, as soon as the article that goes with it is accepted.
For now, I still need help! Well, it basically works on Linux and Mac, with some bugs, but I guess I cannot really do much at the moment (valgrind tells me I want to use too much memory so it stops before saying anything useful).
Now, I just tried under Windows. I used to have a version which worked - but which was slow because during initialization, I generate big matrices that in the last version, I manually entered. Anyway, it works fine for Linux and Mac, and now, under Windows, with a cross compiled version, when I launch SV, it tells me:
--- Code: ---This application has requested the Runtime to terminate it in an unusual way. Please contact ...
--- End code ---
Trying with the provided windows vamp-plugin-tester, I get the same error, and just before, something that goes:
--- Code: ---terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
--- End code ---
Any idea what might have gone wrong, and if I can solve this problem? I am only asking whether there would be an obvious answer (not much hope). Otherwise, I know I might need to check better the linux version, maybe some bugs may give a hint about that particular problem. But I still think it s a bit strange that it should crash right from the start under windows, while the other versions can work almost without bugs...
Cheers!
cannam:
--- Quote ---Is this a limitation of Vamp plug-ins in general, or would it be something possible within SV in the (hopefully near) future?
--- End quote ---
It's a limitation of SV, not of the plugin format. It would certainly be possible to implement it...
--- Quote ---
--- Code: ---vamp-plugin-tester(2548,0xa03f4540) malloc: *** error for object 0x4001e0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
--- End code ---
After 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?
--- End quote ---
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.
--- Quote ---Anyway, it works fine for Linux and Mac, and now, under Windows, with a cross compiled version, when I launch SV, it tells me:
--- Code: ---This application has requested the Runtime to terminate it in an unusual way. Please contact ...
--- End code ---
Trying with the provided windows vamp-plugin-tester, I get the same error, and just before, something that goes:
--- Code: ---terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
--- End code ---
--- End quote ---
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
--- Code: ---float *f = new float[n - m];
--- End code ---
may cause that exception to be thrown if either n or m is unsigned and n is smaller than m.
As this is a C++ exception, it's possible to catch it rather than permit the program to crash -- but it's usually a waste of time; there's not really any reliable way to recover from running out of memory, especially if you don't know at what point in the program the failure happens.
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.
Chris
jean-louis:
--- Quote from: cannam on January 07, 2011, 14:51:27 ---It's a limitation of SV, not of the plugin format. It would certainly be possible to implement it...
--- End quote ---
That would be an interesting addition to SV! Well, assuming there are enough other vamp plug-ins that are developed. I guess this is an on-going project anyway, at QMUL?
Well, if I think about it, it would be great to be able to at least 1) select which output to display and 2) select whether they appear as new panes or new layers.
--- Quote ---
--- Quote ---Trying with the provided windows vamp-plugin-tester, I get the same error, and just before, something that goes:
--- Code: ---terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
--- End code ---
--- End quote ---
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
--- Code: ---float *f = new float[n - m];
--- End code ---
may cause that exception to be thrown if either n or m is unsigned and n is smaller than m.
As this is a C++ exception, it's possible to catch it rather than permit the program to crash -- but it's usually a waste of time; there's not really any reliable way to recover from running out of memory, especially if you don't know at what point in the program the failure happens.
--- End quote ---
What surprises me is that it occurs while loading the program, and not when calling the plug-in. Furthermore, this error did not (yet...) appear with my tests under Linux and MacOsX. Could it be that under Linux and OSX, the memory management allows bigger allocations? Is there any known way to allow more under Windows (at compilation or from Windows)? At least trying this before looking for something else...
--- Quote ---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.
--- End quote ---
Any experience with a debugger under Windows? Or does gdb (or ddd) work with wine?
Thanks for your help!
jean-louis:
Some more comments on the previous matters.
--- Quote from: cannam on January 07, 2011, 14:51:27 ---
--- Quote ---
--- Code: ---vamp-plugin-tester(2548,0xa03f4540) malloc: *** error for object 0x4001e0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
--- End code ---
After 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?
--- End quote ---
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.
--- End quote ---
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:
--- 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? 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?).
--- Quote ---
--- Quote ---Anyway, it works fine for Linux and Mac, and now, under Windows, with a cross compiled version, when I launch SV, it tells me:
--- Code: ---This application has requested the Runtime to terminate it in an unusual way. Please contact ...
--- End code ---
Trying with the provided windows vamp-plugin-tester, I get the same error, and just before, something that goes:
--- Code: ---terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
--- End code ---
--- End quote ---
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
--- Code: ---float *f = new float[n - m];
--- End code ---
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.
--- End quote ---
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.
Regards,
Jean-Louis
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version