#222 Crash looking for vamp plugins

Mercurial tip
open
nobody
None
5
2016-10-06
2016-10-05
No

Problem exists on mercurial tip, but also seen with default Ubuntu 16.04 package installation. Trying to launch sv cores when looking for plugins. I currently have vamp-plugin-sdk v2.5, also does it with vamp-plugin-sdk tip.

Starting program: /home/nps/Workspace/sonic-visualiser/sonic-visualiser 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe2efc700 (LWP 13114)]
failed to get the current screen resources
[New Thread 0x7fffd9417700 (LWP 13115)]
[New Thread 0x7fffd8c16700 (LWP 13116)]
[New Thread 0x7fffd8415700 (LWP 13117)]
[New Thread 0x7fffd7c14700 (LWP 13118)]
[New Thread 0x7fffd7413700 (LWP 13119)]
[New Thread 0x7fffd6c12700 (LWP 13120)]
[New Thread 0x7fffd6411700 (LWP 13121)]
[New Thread 0x7fffd5c10700 (LWP 13122)]
QXcbConnection: XCB error: 172 (Unknown), sequence: 163, resource id: 128, major code: 149 (Unknown), minor code: 20
INFO: Found abandoned temporary directory from a previous, defunct process
(pid=12768, directory="/home/nps/.local/share/sonic-visualiser/Sonic Visualiser/sv_SzY1Lb").  Removing it...
...done.
[New Thread 0x7fffd51d7700 (LWP 13282)]
pitch 69 note 9 octave 4 cents 0
22050 samples at rate 44100
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

Thread 1 "sonic-visualise" received signal SIGABRT, Aborted.
0x00007ffff2e0d418 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff2e0d418 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff2e0f01a in __GI_abort () at abort.c:89
#2  0x00007ffff374f84d in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff374d6b6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff374d701 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff374d919 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007ffff3776082 in std::__throw_bad_alloc() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x00007fffd47c5c6a in std::vector<_VampPlugin::Vamp::PluginBase::ParameterDescriptor, std::allocator<_VampPlugin::Vamp::PluginBase::ParameterDescriptor> >::operator= (this=0x3336, 
    __x=<error reading variable: Cannot access memory at address 0x333e>)
    at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/ext/new_allocator.h:86
#8  0x00007fffd47c0128 in _VampPlugin::Vamp::PluginAdapterBase::Impl::getDescriptor (this=0xe24de0)
    at src/vamp-sdk/PluginAdapter.cpp:190
#9  0x0000000000632908 in FeatureExtractionPluginFactory::getPluginIdentifiers() ()
#10 0x000000000062f37b in FeatureExtractionPluginFactory::getAllPluginIdentifiers() ()
#11 0x000000000066db81 in TransformFactory::populateFeatureExtractionPlugins(std::map<QString, TransformDescription, std::less<QString>, std::allocator<std::pair<QString const, TransformDescription> > >&) ()
#12 0x0000000000671efb in TransformFactory::populateTransforms() ()
#13 0x0000000000673cdc in TransformFactory::getAllTransformDescriptions() ()
#14 0x000000000045b596 in MainWindow::setupTransformsMenu() ()
#15 0x0000000000448438 in MainWindow::setupMenus() ()
#16 0x000000000046db73 in MainWindow::MainWindow(bool, bool) ()
#17 0x000000000043e6bc in main ()

Discussion

  • Nathan Stewart

    Nathan Stewart - 2016-10-05

    Apparently this is indeed a problem of the plugin, however it seems that sv should be able to catch the exception.

     
  • Chris Cannam

    Chris Cannam - 2016-10-06

    Do you happen to know which plugin is causing this?

    If you're building from hg, then perhaps try the 3.0-integration branch. This contains some work targeted for the next major release, including a separate process which is used on startup to scan for plugins and eliminate any that crash on instantiation. However, it may be ever more fiddly to build and run than the default branch is!

     
  • Nathan Stewart

    Nathan Stewart - 2016-10-06

    I think this was a compilation issue with gcc v4/5. I did encounter this with all prebuilt packages though. It ended up being vamp-aubio that was the particular culprit.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks