Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Muse2 2.1.1 Segfaults
#1
Hi,

I am the maintainer of AV Linux and am trying to build updated packages for Muse2 to be included on the next ISO, I have built and packaged Muse2 previously with no issues however for some reason 2.1.1 is giving me segfaults. I am certain all dependencies are present and the compilation and packaging steps all go without a hitch. When I go to run Muse2 I get the splash screen and shortly after the program segfaults and terminates. I am using ccmake to do the builds (which has worked previously) and the only change I'm making is to change the install prefix to /usr. I will confess to being less familiar with Muse2 then the numerous other sequencers included in AV Linux but I'm hoping I've just missed something obvious somewhere along the line..

For now all I have is this terminal output, please advise what you suggest for how to better investigate, I have used gdb but not recently and my debugging skills are a bit rusty..

*Note - I am aware that I should have rtc permissions, this is just from a development build machine.

Code:
glen@av6devdesk:~$ muse2
LOCALE en_US
open projectfile: No such file or directory
Denormal protection enabled.
Trying RTC timer...
RtcTimer::setTimerFreq(): cannot set freq 1024 on /dev/rtc: Permission denied
  precise timer not available, check file permissions and allowed RTC freq (/sys/class/rtc/rtc0/max_user_freq)
Trying ALSA timer...
AlsaTimer::initTimer(): best available ALSA timer: system timer
got timer = 73
Aquired timer frequency: 1000
RemoteVSTClient: all cache files are up-to-date, not running scanner
RemoteVSTClient: all cache files are up-to-date, not running scanner
Segmentation fault
glen@av6devdesk:~$
Reply
#2
Hi gmaq,

first, wow, AV Linux is still alive, great! <!-- sSmile --><img src="{SMILIES_PATH}/icon_e_smile.gif" alt="Smile" title="Smile" /><!-- sSmile -->
I was introduced to AV Linux just a while ago and was very pleasantly surprised of the quality, thank you!
I can't remember where I got it from but I had gotten the impression AV Linux was no longer being maintained, great that it still is updated!

As to the error, I think this may be due to the new support for Native VSTs, there are some VSTs in AVL, right? We know there are some VSTs that don't play nicely with MusE yet.
To verify this try starting MusE without Native VST support: muse2 -N
You could also start MusE with -D to get more printouts.

As for the RTC issue, MusE falls back on alsa-timer, and according to the trace it got a 1000hz timer which should suffice.

We'll start from there see if we can isolate the issue.

Regards,
Robert
Reply
#3
Hi,

Wow, thanks for the quick and courteous reply!

Yes, AV Linux was supposed to not see further development but I've been able to resume work on the 6.X version and will soon be releasing AV Linux 6.0.1...anyway enough about me <!-- sSmile --><img src="{SMILIES_PATH}/icon_e_smile.gif" alt="Smile" title="Smile" /><!-- sSmile -->

With your helpful information I've determined that you are absolutely correct and using the '-N' parameter allows Muse2 to launch as normal, with some further investigation using '-D' it appears one (or more) of the 'DISTRHO' linuxVST's is causing the issue. This is a bit of a conundrum because AV Linux has both a large amount of Native linuxVST's in 2 locations and a small amount of free Windows VST's included. I generally use usr/local/lib/linux_vst for Native and /usr/local/lib/vst for Windows but unfortunately the various sequencing programs have varying ways of parsing plugins on the system and differing ways of handling directories. For example Ardour searches for 'lxvst' folders by default.

Anyway for now I have success getting Muse2 to launch if it parses my /usr/local/lib/linux_vst only, the DISTRHO plugins reside in /usr/lib/vst so for now I can just include a little script to export a custom VST_PATH to Muse2 to get things up and running until you have sufficient time to work around any troublesome plugins.

Thanks again for your help, keep up the great work, I look forward to getting a bit better acquainted with Muse2.. <!-- sWink --><img src="{SMILIES_PATH}/icon_e_wink.gif" alt="Wink" title="Wink" /><!-- sWink -->
Reply
#4
Hi. I wrote the Native VST support.

You can tell MusE where to look for the plugins: Type muse2 -h for help.

Some useful environment variables:
LADSPA_PATH: Override where to look for ladspa plugins, or else
~/ladspa:/usr/local/lib64/ladspa:/usr/lib64/ladspa:/usr/local/lib/ladspa:/usr/lib/ladspa

DSSI_PATH: Override where to look for dssi plugins (dssi-vst plugins: VST_PATH), or else
~/dssi:/usr/local/lib64/dssi:/usr/lib64/dssi:/usr/local/lib/dssi:/usr/lib/dssi

VST_NATIVE_PATH: Override where to look for native vst plugins, or else VST_PATH, or else
~/vst:/usr/local/lib64/vst:/usr/local/lib/vst:/usr/lib64/vst:/usr/lib/vst

If this causes problems for you maybe I should rename those env variables to something
more specific like MUSE_VST_NATIVE_PATH, but hey I was just trying to be consistent
with VST_PATH, I figured maybe VST_NATIVE_PATH would become 'standard' but I suppose
paradoxically in this case if it were shared among apps you wouldn't be able to isolate things
easily, eh?

We support Win VSTs via DSSI-VST but not directly ('natively'). May try at some point.

I'd be interested in knowing which plugin(s) are causing the segfault.
Can you please post the output of running muse2 with the -D switch. It should help me.
(Or else, isolate which ones for us by setting up a folder and one-by-one trying them.)

I know of a couple that didn't work. It seemed to me that they might be... alpha quality.
I've tested quite a few such as Aspect, Discovery, String (+ FX), all the TAL plugins,
ToneSpace, Vex and more. Got 'em all installed here and MusE loads fine.

One problem I am aware of though, is that with several of these plugins which I believe
were made with JUCE, there is a known problem that they cause MusE to crash upon shutdown.
Actually QTractor's code also mentions this. The author's workaround was to NOT unload any of the plugins.
I did not do that, since that is memory leaking. So I dutifully unload them and figured, hey let the
plugins get fixed over time, hopefully they will be solved as they get compiled with newer JUCE versions ?

I also know there's one or two pesky ones that open in QTractor but not in MusE. Researching this.
But there are also a couple that cause QTractor to crash but not MusE.
Go figure, eh? He he...

Thanks for your help. Let us know if any other problems or anything we can help with.
The SVN repo is where the excitement happens literally by the hour, but we're trying
to release more often now thanks to Robert. Should be another one soon.

Tim.
Reply
#5
Hi Tim,

Thanks for the reply and clarification. I am close to a finished ISO and short on time but I will try and narrow things down further, at least I know it is pretty much confined to DISTRHO/JUCE so I may try one at a time and see what blows things up. If I get that far I will post back here with the output. All you DAW guys keep me on the run so I am no stranger to SVN/GIT but I prefer not to package from there if possible. AV Linux comes with all build dependencies for Muse2 (and most other included programs) pre-installed so I leave the real bleeding edge investigation to the keeners who get off on such things <!-- sWink --><img src="{SMILIES_PATH}/icon_e_wink.gif" alt="Wink" title="Wink" /><!-- sWink -->

I will admit in my ignorance I was a bit passe about Muse2 having been an Ardour user personally for many years but having played around with it a bit more it has some really interesting and useful features. Keep it up guys!
Reply
#6
terminator356 Wrote:Actually QTractor's code also mentions this. The author's workaround was to NOT unload any of the plugins.
I did not do that, since that is memory leaking

Sorry, a clarification:
QTractor skips explicit library unloading but I think they're still unloaded anyway:

// HACK: JUCE based VST plugins, which are the most found
// with a GUI editor, need to skip explicit shared library
// unloading, to avoid mysterious crashes later...
if (m_bEditor) file()->setAutoUnload(false);

And later:
if (m_bAutoUnload) QLibrary::unload();

And the QLibrary::unload() docs say:
"This happens automatically on application termination, so you shouldn't normally need to call this function. "

Apologies for the misinformation.
Tim.
Reply
#7
Tim,

This unloading, does it happen during initialization or is it when MusE is closed?

Previously there was a crash reported for AVL6 with a drumplugin, I can supply the .so file in a while.
Not sure it's the same, it worked most of the time, still it might be good to take a look at.

Regards,
Robert
Reply
#8
spamatica Wrote:This unloading, does it happen during initialization or is it when MusE is closed?

Previously there was a crash reported for AVL6 with a drumplugin, I can supply the .so file in a while.
Not sure it's the same, it worked most of the time, still it might be good to take a look at.

Each plugin library is loaded and unloaded once during scanning (the part that fills the plugin list).
This loading is essentially a 'fake' do-nothing do-not-activate load simply to see inside - it's name, capabilities etc.

Then, if a plugin is later actually instantiated by the user, the library is loaded of course, this time for 'real' with
activation and so on, and then later at shutdown it is explicitly unloaded.

Notice that the 'fake' scanning load does not cause most of them to crash upon corresponding unload, that is,
the ones which cause crash at 'true' instantiated unload at shutdown, do not crash here at 'fake' unload.

In other words instantiating and activating some of them, makes unloading them worse than not activating them.

I tried a bunch 'o stuff. Only not explicitly unloading them at shutdown prevented the crashes.
I looked at using c++ exceptions to catch the errors (which I used religously in Windows) but was surprised to
see they are kind of frowned upon, I know the reasons why but they used to offer me a measure of safety...
One, maybe two caused a crash even at the 'fake' load/unload, but I think I've kinda smoothed that out.
That part is basic library loading/unloading. It either works or doesn't. Not much the app can do beyond that I think.

Maybe we should try using QLibrary for all our library operations. Our dlclose needs to be called explicitly
if I understand the docs (it holds a reference count) but apparently not so with QLibrary.
Just an anecdote: I had trouble using fork and exec when trying to load DSSI GUIs, the libraries were left hanging around
at close, and I just could not figure out how to solve it. So I switched to QProcess and everything worked great. Hint hint...

Tim.
Reply
#9
terminator356 Wrote:Maybe we should try using QLibrary

I tried QLibrary this evening. Same result - crash at shutdown.
And my mistake I forgot, it's worse than I said:
It crashes even when I don't instantiate any of the plugins.
Just from opening and closing them during scanning, and nothing else,
it crashes at shutdown usually around ~MuseApplication(), during some
libc and X11 stuff or some mutex unlock.
I was mistaken earlier, during scanning the effect itself is in fact opened (instantiated)
to see what is in it, then closed.

So I read up on some stuff: An app gives up all heap memory at close. That means even with
dlopen() the app releases all memory at close even without explicit dlclose().
(And contrary to common myth, this even goes for stuff like 'malloc' and 'new', an app
gives up all heap memory at close, without free() or delete.)

So even though I am opening then closing the libraries at scanning time, at app close time
I'm guessing the app tries to give up the QLibrary or dlopen object (but why? I closed it)
and it's encountering some kind of error.
I later also tried completely removing all dlclose() (or QLibrary::unload()), and just let
the system take care of them at close time.
And the darn thing still crashes!

I found it was certain plugins, unfortunately some nice ones. I'll try to check some more.

In the end it might be plain old namespace collision + corruption like we've seen before in MusE,
likely with the JUCE variables that are common to all the plugins that crash MusE.
This might explain why QTractor does not crash at close, yet using QLibrary in MusE still failed.

Or I could have simply made a coding mistake.

I've looked many times at the VST callback but that shouldn't be it because only one function
is used during scanning - the version 'getter'.

We'll see how it goes. Stay tuned...
Tim.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)