Author Topic: BASSWV 2.4.6 for Linux x64 crashes on BASS_PluginLoad  (Read 1003 times)


  • Posts: 116
It crashes with this backtrace from gdb:

Code: [Select]
Thread 6 "deadbeef-stream" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffdefec700 (LWP 9780)]
0x00007fffdc27f9d9 in ?? () from /usr/lib/
(gdb) bt
#0  0x00007fffdc27f9d9 in  () at /usr/lib/
#1  0x00007ffff7fe8155 in _dl_close_worker () at /lib64/
#2  0x00007ffff7fe6f28 in _dl_open () at /lib64/
#3  0x00007ffff7f8315a in  () at /usr/lib/
#4  0x00007ffff7d4ff57 in _dl_catch_exception () at /usr/lib/
#5  0x00007ffff7d4fff3 in _dl_catch_error () at /usr/lib/
#6  0x00007ffff7f838bf in  () at /usr/lib/
#7  0x00007ffff7f831fa in dlopen () at /usr/lib/
#8  0x00007fffe68740ae in BASS_PluginLoad () at /usr/lib/
#9  0x00007fffe6ab1697 in BMPlayer::BMPlayer() () at /usr/lib/deadbeef/
#10 0x00007fffe6aafe11 in midi_open_file_for_decode(midi_info_t*) ()
    at /usr/lib/deadbeef/
#11 0x00007fffe6ab012c in midi_init(DB_fileinfo_s*, DB_playItem_s*) ()
    at /usr/lib/deadbeef/
#12 0x0000555555594556 in  ()
#13 0x0000555555597fe8 in  ()
#14 0x00007ffff7de3a9d in start_thread () at /usr/lib/
#15 0x00007ffff7d13b23 in clone () at /usr/lib/

Ian @ un4seen

  • Administrator
  • Posts: 22741
I don't seem to be able to reproduce that here, with either the PLUGINS example from the BASS package or the MIDITEST example from the BASSMIDI package. Please see if you can reproduce the problem with either of them there (run "make" in an example's folder to build it).


  • Posts: 116
Would it conflict if loaded into the same process as the system's copy of libwavpack? I can provide a loaded modules list from another crash, so it lines up with the actual crash address.

Ian @ un4seen

  • Administrator
  • Posts: 22741
BASSWV won't be affected by the system's libwavpack. Please do provide the modules list/addresses, along with the call stack, the registers, and a small assembly listing from the crash location. Also confirm that you are using the latest BASS and BASSWV versions.

Are other add-ons loading fine via BASS_PluginLoad?

Please do also try to reproduce the problem with the BASS/BASSMIDI examples, and if you can reproduce it with them, state what Linux version you're using so that I will hopefully be able to reproduce it too then.


  • Posts: 116
I can't reproduce the issue with miditest. I just downloaded the archives from this site a few days ago, so I think I'm using the latest versions. I installed them system wide, and doctored the Makefiles to leave off the rpath declarations, and they still load just fine with miditest.

It must be something up with my MIDI plugin build process. I'll throw together a Makefile for it, but I don't know what else could be up. The BASSFLAC addon isn't working with it, either. I can only load SF2Pack files compressed with Ogg Vorbis, but not FLAC. (Possibly MP3 would work, but I haven't tried that.)

Here is the source tree I use to build the plugin:

I use the Makefile in the plugins/midi directory, and it expects installed BASS/BASSMIDI/plugins.

Crash and trace from trying to load basswv:

Code: [Select]
backtrace() returned 18 addresses
deadbeef(+0x32d9a) [0x561caf3c0d9a]
/usr/lib/ [0x7fd09f515e00]
/usr/lib/ [0x7fd0845a99d9]
/lib64/ [0x7fd09f8ab155]
/lib64/ [0x7fd09f8a9f28]
/usr/lib/ [0x7fd09f84915a]
/usr/lib/ [0x7fd09f615f57]
/usr/lib/ [0x7fd09f615ff3]
/usr/lib/ [0x7fd09f8498bf]
/usr/lib/ [0x7fd09f8491fa]
/usr/lib/ [0x7fd08e6540ae]
/usr/lib/deadbeef/ [0x7fd08eb0d638]
/usr/lib/deadbeef/ [0x7fd08eb0bde1]
/usr/lib/deadbeef/ [0x7fd08eb0c0fc]
deadbeef(+0x40556) [0x561caf3ce556]
deadbeef(+0x43fe8) [0x561caf3d1fe8]
/usr/lib/ [0x7fd09f6a9a9d]
/usr/lib/ [0x7fd09f5d9b23]
Segmentation fault (core dumped)
« Last Edit: 16 Feb '19 - 09:14 by kode54 »

Ian @ un4seen

  • Administrator
  • Posts: 22741
That crash location appears to be in BASSWV's destructor function (called when BASSWV is unloaded). It seems as if BASSWV's constructor function wasn't called first, leaving variables that the destructor accesses (including a pointer) uninitialized. I'm not sure what would cause that to happen. Perhaps the initial problem was in the constructor and the destructor was called before it finished. I'll send you a debug version to try to confirm whether that is the case.


  • Posts: 116
Clarifying for this topic, it was partially my fault. I linked libbass to my plugin, but it didn't bring it into the public namespace that BASS plugins need to import symbols from it. Thanks for the fix, I just need to call this before importing the plugins:

Code: [Select]